|
|
NET 226 - Designing Internetwork Solutions
Chapter 9, Developing Network Management Strategies
Objectives:
This lesson concerns making choices about managing your
network. Objectives important to this lesson:
- Network management design
- Network management architectures
- Selecting tools and protocols
Chapter 9
Network management design
The
text recommends that we should consider management of a network "from
the beginning" of our design process. There have been a few hints about
this along the way, and now we have a chapter about it. The text
recommends that we select our management tools carefully, because too
much measurement will slow down the network, and too little will not
give us reliable data on its performance. The text suggests on page 264
that we should use proactive
management, measuring the performance during regular operations
so we can recognized normal performance and see any trouble as it
develops. Reactive management
measures performance only when there is a suspected problem, which can
be less time consuming, but it does not give us a baseline for network
performance, and it will not find problems as they develop, which is a
better way to avoid down time.
The text introduces five categories of management that are
endorsed by ISO:
- Fault management -
This is about managing problems
and failures. The text states
that it includes reporting problems
to users, which is a function that many IT people consider as an
afterthought. Communication with our customers about problems is not an
option, it is a requirement. The text recommends that we have reporting
tools and problem documentation tools along with tools to monitor and
detect problems. Such tools are often based on Simple Network
Management Protocol (SNMP) and Remote Monitoring (RMON). The text
mentions that Cisco devices produce messages about faults that are
tagged with one of eight levels of importance. These messages can be
sent to a network management system if desired.
- Configuration
management - Devices, whether on or off a network, can often be
installed in several different ways, and they can be configured differently by each
person who installs them. A configuration
management system can help us provide a standard configuration for various
devices, and manage allowed customization. This kind of system
can also be used to build and maintain an inventory of network-attached
devices. The text mentions that DHCP is an example of a protocol that
supports these ideas, and that VLAN Trunking Protocol (VTP) is useful
for updating switches with information about VLANs.
- Accounting
management - The text explains that the purpose of accounting
management software is to measure use of a network, typically for billing for actual usage. There is
also a value to such a system as a problem
detection tool, because it will detect large scale usages of
network resources which can be examined for abuse or actual business need.
- Performance
management - The text lists several types of performance that should be
measured on a network. It clusters them into two categories: end-to-end performance describes
performance across all components used in a network service, and component performance measures the
performance of specific devices. Measuring the performance of a network
from one extremity to another is often done to measure what is supposed
to be the performance across the farthest distance. The text mentions
that a ping is commonly used for a quick test of this sort, and reminds
us that a ping is actually an Internet Control Message Protocol (ICMP) echo request. It is not common
for the farthest points in a network to be in the busiest circuits, so
we should expect to measure heavily used routes as well, measuring the
throughput between various points to find bottlenecks. The text
cautions us not to depend on
measurements taken with traceroute,
because some routers are not programmed to respond as the protocol
assumes they will. (See pages 267 and 268.)
- Security management
- A security management system should asssist in providing IDs and passwords to users, in creating and
managing encryption keys, and
in analyzing the security features
of networking and internetworking devices. A security management system
should also examine audit logs, which may be created by security or
accounting processes
Network management architectures
The text presents a short section on architectures, which may
be best understood by examining the graphic on page 269. There are
three parts to the architecture displayed there:
- a managed device -
Almost any device on a network may be used to collect and report
information to a management system. The text suggests routers, servers,
switches, bridges, hubs, end user systems, and printers.
- an agent - Software
that runs on the managed device to collect network information. After
collection, the agent will pass the data to the next level in the
architecture.
- a network management system (NMS)
- May be implemented as a database and aanalysis system running on
higher end hardware. It controls the managed devices and its agents,
and it provides analysis and reports from the data. There may be a
separate NMS for each kind of management being done on the network.
Network management may be done in-band or out-of-band. In-band systems use the network they are monitoring to carry their data to the NMS. Out-of-band systems use a separate channel to carry their data.
Selecting tools and protocols
SNMP - As discussed
above, this protocol is a standard for management systems. The text
recommends SNMPv3 or later for better security and authentication
features.
Management Information Base (MIB)
- The description in the text matches thhe discussion of architectures
above. An MIB gathers information from deployed agents and looks for
problems in the network.
Remote Monitoring (RMON)
- The IETF apparently felt that MIBs didd not collect adequate
information on traffic in the bottom two layers of the ISO network
model. They developed RMON to watch for problems in these layers.
The
chapter concludes with a discussion of some Cisco protocols that also
provide management and troubleshooting information. You should review
the summary of protocols discussed in the
chapter that appears on page 277.
|
