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 devices
  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 Todays 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 gt /proc/sys/net/ipv4/ip-forward
• Create IP routing state from customer to
  tunnel
• echo 202 tun-1-2 gt /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 gt /etc/iproute2/rt_tables
• ip rule add iff greA table tun-2-1
• ip route add default dev eth0 table tun-2-1

18
GRE Tunneling Todays 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 gt /proc/sys/net/ipv4/ip-forward
• Create IP routing state from customer to
  tunnel
• echo 202 tun-1-2 gt /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 gt /etc/iproute2/rt_tables
• ip rule add iff greA 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 ltETH, A, egt and ltETH, B, egt

21
GRE Tunneling NM Implementation

• NM gets CONMan abstractions from all the modules
  involved lt showPotential() gt
• 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 (contd)

• 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