|
|
|
Managing Multivendor Networks
  
- 11 -
Network Management
In the past, network management was primarily a centralized endeavor carried out
by a virtual priesthood of technicians who stared at arcane command-line screens
all day. The growth of the distributed, client/server enterprise model has significantly
changed the face of network management--simplifying it in some areas, while clouding
it even further in others. Management tasks can now be distributed to the most appropriate
machine, and various tasks executing on different platforms can now, under some circumstances,
be integrated.
The Problems of Problem Determination
Networks were once either centralized or covered a relatively small local area.
When data communications or networking problems involved leased or dialable lines,
the long distance carrier stepped in and ran loopback tests until the problem was
isolated (or until the data communication analyst resolved it out of boredom or desperation).
Today's networking picture is much larger and more complicated. Simple coaxial-based
LANs now interface with fiber-optic metropolitan area networks (MANs) that,
in turn, interface with one another to form WANs. The centralized point-to-point
connections used in the past have been replaced with large, gray clouds of packet/cell
switching networks or dual-purpose voice/data ISDN connections. Not all of these
changes create problems. In fact, the opening of voice circuits to the general (albeit
often unsuspecting) public has enabled many companies to implement combined voice/data
networks. These have resulted in highly effective, multiple vendor networks that
also produce large cost savings--not a bad package.
These types of combined networks are extremely frequent in large manufacturing
operations, such as U.S. car manufacturers. In this scale of operation, it is often
typical to find a broadband network running through the local plants to handle the
combined voice/data traffic. The broadband networks within the plants can then be
tied together via direct satellite (effective, but a little pricey), more conventional
T1, X.25, or ISDN links, or high-speed ATM or frame-relay connections.
Because such large operations typically involve many different computer systems
that must exchange data having a variety of networking protocols, using a common
set of transports can be more effective than implementing multiple networks and attempting
to bridge them together.
Problem Determination: Centralized
Networks
From a human perspective, fault isolation is normally a rudimentary, logical process
of elimination. The application of this logic is most readily apparent in the case
of centralized (or hierarchical) networks, which feature a rigid and well-defined
structure. If, for example, a user's terminal fails, the problem can be pursued in
one of the following manners, depending on the network architecture (see Figure 11.1).
FIG. 11.1 Points of Failure in Point-to-Point
and Hierarchical Networks
If the terminal is on a point-to-point line to the computer, only three items
need analysis: the terminal, the line, and the line interface in the computer. Running
diagnostics on the terminal and line interface is normally a straightforward procedure.
If devices on both ends pass, the problem is probably in the middle. Line-level diagnostics
can then be performed at the modem level through the use of loopback tests.
The seemingly more complicated case, in which a terminal is on a controller that
interfaces to the main computer via a line, is actually easier to diagnose. In this
scenario, the failure could be at the terminal, the terminal controller, the line,
or the line interface in the main computer. However, because the terminal controller
provides a critical function between the terminals and the computer, the failure
can be more easily isolated. For example, if the terminal controller handles 16 terminals
and only one of the terminals has failed, the problem can be isolated to the terminal
(or its connection to the terminal controller). Diagnostics can then be run on the
terminal to determine if it indeed is the point of failure. If all terminals fail,
the problem should be pursued first at the terminal controller. Because most terminal
controllers are intelligent devices, diagnostic routines can be used to further determine
whether it has a failure.
Most terminal controllers will report the loss of a line (indicating problems
at the line or line interface level). Therefore, further isolation can be performed
by running the line interface diagnostics in the mainframe, or by running loopback
tests on the line. The key point in all of this is that the introduction of additional
hardware (in other words, the terminal controller) in a hierarchical network does
not complicate problem analysis; instead, the structure of the network and the well-defined
relationship between network components actually assists in the troubleshooting process.
Although both of the previous environments might seem relatively easy to troubleshoot,
in actual environments the problem is usually compounded by the sheer number of devices
involved. In a large SNA network, it is not unusual to find thousands (or even tens
of thousands) of terminals distributed across hundreds or thousands of line controllers,
lines, and terminal controllers. So although a failure in a terminal might not be
very difficult to diagnose, determining which terminal controller, line, and line
interface is associated with that terminal can be an awesome task.
Problem Determination: LANs
The degree of difficulty of problem determination in a LAN depends on both the
topology and the discipline of the LAN. The three basic topologies (ring, star, and
bus) all require different types and amounts of cables and connection devices. As
with virtually every manufactured product, when the component count increases, so
do the possible points of failures. The three general LAN types (see Figure 11.2)
have specific peculiarities, as described in the following paragraphs.
FIG. 11.2 Examples of Ring, Star, and Bus
Networks
In a token-passing ring network (for example, IEEE 802.5), the frame being
passed from one computer to the next is on the ring. Therefore, any break in the
ring is critical to the operation of a token-ring network. To prevent this tragedy,
the cabling and connection systems of most ring networks are self-healing--specifically,
circuits automatically close when cables are detached from computers on the ring.
In fact, most token-ring networks are cabled using central hubs, resulting in a physical
layout that looks very much like star networks (described next).
In a star network, individual computers are attached to one another via
hub units. Star networks can be operated on either a contention basis, where each
computer competes with the other computers for access to the network, or can be token-passing.
In either case, the hubs are common points through which all data flows.
Bus networks are widely used in contention networks (as in Ethernet and
IEEE 802.3 networks), although they are occasionally used with token passing networks
(as in IEEE 802.4). In the most basic case, a bus LAN is a single main cable to which
computers attach. As in the case of the ring, the integrity of the main path must
be kept intact and all connections must be properly terminated--if an "open"
connection is present in the network (in other words, a cable run with no termination
at the end), the network will be unusable.
Despite these differences, any malfunction in any of these networks translates
into one common problem: finding the point of failure. And regardless of the LAN
of choice, discovery is no cake walk. One reason for this difficulty is that LANs
do not have the direct user-to-node relationships that centralized networks have.
For example, a terminal failure in a centralized network is normally reported by
the user who wants to use that terminal. Therefore, if a terminal is broken and no
one wants to access it, it might go unreported for a long time. On the other end
of the spectrum, if the central computer fails, all users will notice it and the
source of the problem will become quickly evident.
In a LAN, however, each node is a potential resource for other nodes. Even though
no one might be directly attending a PC, it might be in use by the network at large
because it contains files or controls a printer used by other PCs in the network.
Because of these interdependencies, the absence of a resource is normally evident
more quickly and is usually more critical to the overall operation.
Although the discussion to this point has focused on hard failures in a node,
more serious problems are a node that intermittently fails or a malfunction that
corrupts the information (and therefore degrades performance). These types of problems
are much more difficult to diagnose than hard failures, because there is rarely a
point from which to start. The use of monitoring equipment or software is instrumental
in isolating these types of problems, because the condition is rarely reproducible
or trackable by mere mortals.
And finally, some problems cannot be diagnosed--no matter how much diagnostic
equipment and software is used. If, for example, a network goes into an extremely
degraded condition every Thursday between 2 and 3 p.m., it might take months or years
to learn that an overhead Air Force plane is performing advanced radar testing on
that same schedule. Sometimes the big picture of network troubleshooting gets pretty
large.
Problem Determination: WANs
Whereas LANs are more complex to troubleshoot than centralized networks, MANs
and WANs are more difficult to manage than LANs. For one thing, both MANs and WANs
typically interconnect other networks, so a MAN or WAN is a collection of networks,
each of which is difficult to manage in itself.
Consider the network pictured in Figure 11.3. A LAN of PCs performs manufacturing
functions, while a LAN of PCs with an attached midrange computer handles shipping
functions. Two central systems servicing traditional terminal networks are then responsible
for the accounting and administrative/sales functions, respectively. And all four
of these networks are tied together through high-speed, digital (T1) links.
FIG. 11.3 Sample WAN
In this example environment, the flow of information between Manufacturing, Shipping,
and Accounting is critical. It enables the company to track and coordinate parts
received, final goods in inventory, shipments, and billings. The Sales/Administration
system relies on information maintained by the other systems for tracking the status
of customer orders or finding the availability of inventoried goods.
Each of the self-contained networks within the larger WAN has critical dependencies
on one or more of the other small networks. If, in the example, the manufacturing
LAN fails to communicate with the accounting system, important information is no
longer being reported--parts received can no longer be tied to accounts payable,
and new inventory cannot be added into assets. Therefore, any problem within any
of the networks is critical to the entire network.
But the network analyst (who is probably not located where the failure is) must
determine if the problem is in the manufacturing LAN or in the link between the LAN
and the accounting system. Fortunately, the approach taken here is similar to the
approach used for centralized networks. A quick call to the manufacturing operation
should determine if the problem is the LAN itself or the link between the LAN and
the accounting system. If the problem is in the link, the troubleshooter needs to
pursue the bridge between the LAN and the link, the line interface on the manufacturing
system, and, of course, the line itself.
Again, the problem is not insurmountable when analyzed in its own right. But when
the network grows to worldwide size and interconnects many different centralized
systems, LANs, and MANs, the problem becomes much more intense because of the scale
and number of variables. A link between Kansas and Ohio might use T1 transmission,
but a link between New York and Denmark might use a third-party, worldwide packet-switching
network (PSN).
A WAN-wide failure can be simultaneously evasive and disastrous. Let's go back
to the example of the large manufacturer using a broadband network. Broadband is
a high-bandwidth data communications scheme capable of transmitting voice, video,
and data simultaneously. Therefore if a forklift runs over the broadband cable and
severs it, all kinds of systems will be affected (for example, computers, telephones,
and teleconferencing equipment) If, on the other hand, a minor electrical component
fails in a computer or interface device causing distortion or degradation on the
broadband network, only selected operations will be affected, and sorting through
the confusion will be a chore.
Given these large networks and the complex problems they pose, the need for network
diagnostic equipment and software should be obvious.
Approaches to Network Management
Network management is best facilitated when the lowest layers of the networking
and data communications software are sensitive to failures and capable of reporting
them. Furthermore, the best possible network management solution uses intelligent
equipment at all levels-- equipment that is capable of detecting errors in itself
and in the equipment with which it interfaces, automatically notifying personnel
of the situation, and executing the repair of some common problems. Ideally, terminal
controllers report workstation failures, modems report line problems, and LAN interfaces
in computers report any irregularities they experience.
Many vendors and data communication providers have started to provide this level
of intelligence in their products. However, because networking solutions often involve
mature (or old) data communication solutions, the data communications protocols often
cannot carry (let alone detect) this special information to a common networking management
point.
This lack of integrated network diagnostic products has long fostered the use
of independent, nonintrusive diagnostic products. These products grant visibility
to low-level data communications activities without interfering with the activities.
These types of products include breakout boxes, line monitors, and LAN monitors.
Breakout boxes serve to isolate and display the electrical signals within
an interface. For example, an RS-232 breakout box shows when data is transmitted,
when data is received, and the various electrical interface handshakes that accompany
the transfer of data (that is, Request-to-Send, Clear-to-Send, and so on). Although
these devices do not actually display the data being carried over the interface,
they show all of the other characteristics of the interface. Breakout boxes are available
for a wide variety of interfaces, including LAN interfaces.
In contrast, data communications line monitors can be used to view the
electrical signals and digital information being passed on a standard data communications
line. These monitors perform no detection or isolation on their own; they just provide
a viewport from which the data communications analyst can diagnose the problem. The
evolution of the line monitor was an important step in the development of data communications
management. Before this type of equipment, traditional electronic instruments like
oscilloscopes had to be applied to the individual signal lines, and data was viewed
as analog electrical patterns (square waves, sine waves, and so forth). With line
monitors, the same information appears as digital data that can be viewed in binary
or character format. Line monitors are specialized electronic devices produced, for
the most part, by third-party companies such as Digilog Inc. and Tektronix Inc.
LAN monitors are similar to line monitors, except that they monitor the
traffic and electrical signals operating on a LAN. This equipment tends to be more
sophisticated (and expensive) than line monitors because it must actually interpret
and present the frames (for example, 802.3, 802.5, and Ethernet) for analysis. By
viewing the data at this low level, one monitor can track multiple LAN disciplines
(for example, DECnet, TCP/IP, and Novell IPX) operating on the same physical LAN.
Some LAN monitors can be further keyed into monitoring one or more specific disciplines.
HP is a leading manufacturer of this type of LAN monitor.
Because any computer in any LAN looks at every frame that passes by, software
has been developed for PCs and workstations to perform the function of a LAN monitor.
While operating in this mode, the PC does not typically participate in the network
(although it technically can). Rather, it displays and breaks out frame level and
protocol-level traffic. The popularity of this approach has risen to the point that
many manufacturers (lead by HP and Digital) promote the dedication of PCs or workstations
to this task. In effect, that computer becomes the full-time network monitor. All
major manufacturers and many third-party companies produce software that performs
this function.
NOTE: Microsoft now includes a basic Network Monitor application
in its Windows NT 4.0 operating system. Although it is has only limited functionality,
it has the advantage of being free with Windows NT, and can be very useful in basic
troubleshooting and for viewing network traffic.
Most of the intelligent devices used in networking have special internal diagnostic
routines that perform some confidence testing of the raw hardware and interfaces.
For example, terminals, terminal controllers, modems, and computer interface cards
normally have these diagnostics available. Unfortunately, operating the diagnostics
often involves removing the unit from the network. In many highly distributed WANs,
this might not be a practical approach because the technical personnel might not
be near the equipment in question.
Emulation and exercise equipment is often used to diagnose these remote problems.
This type of equipment emulates the controlling equipment, but instead of running
the live environment, it sends and receives test messages to exercise the remote
equipment and then records and reports any failures. Exercise routines can also be
run by computers instead of specialized instruments. When used in this fashion, the
diagnostics might run concurrently with other network operations (although the devices
being tested will not participate in the normal network activities).
In TCP/IP networks, you do have one other important diagnostic tool: the ping
command. The ping command is a simple TCP/IP utility that sends a test message
out to a system in the network and waits for a response back. If you receive a response,
you then at least know that the system you are testing is properly connected to the
network, and you can then move your tests up to the next level and look at configuration
issues instead of network attachment issues.
It must be noted that the primary purpose of monitoring these diagnostic products
is to aid the network or data communications analyst in determining the problem.
These products do nothing on their own and have little value to non-technical personnel.
In fact, there is a risk associated by allowing non-technical personnel to use monitoring
products, because they will gain visibility to all kinds of information traveling
through the network--for example, passwords, personnel information, and financial
details normally flow through networks unencrypted. This is clearly a good reason
to control who has access to network monitoring products.
Monitoring and diagnostic products are, in reality, just simple tools that pale
in comparison to full-blown network management products. There are a variety of network
management products on the market that range in price from hundreds to millions of
dollars. Originally these products were implemented using proprietary interfaces,
but the industry is know moving toward standards-based network management.
The Desktop Management Interface (DMI), a standard promoted by the Desktop
Management Task Force (DMTF), provides a common management framework for products
and management protocols from different vendors. DMI establishes a standard interface
for communications between management applications and system components. More products
are starting to comply with the specification, which revolves around a Management
Information Format (MIF) database, a language used to specify the manageable
attributes of DMI-compliant devices. MIFs have been released for several basic components,
such as the CPU, operating system, and disk drives. Further MIFs are under development
for network interface cards (NICs), printers, and other devices. Openview for Windows
(HP), LANDesk Manager (Intel), and Systems Management Server (Microsoft) all use
the DMI.
The DMI's Service Layer runs locally, and collects information from devices by
accessing the MIF database. Compliant devices communicate with the Service Layer
through a Component Interface, and pass information to the management applications.
There are some similarities between DMI and SNMP. SNMP, instead of a MIF, stores
data in a management information base (MIB).
In the past, DMI has been limited in scope. The DMI itself, although it specifies
a definition for collecting management information, has no guidelines for passing
data across the network. Without the ability to get information from a remote machine,
DMI is very limited in its usefulness and requires proprietary means to move the
information. The DMTF's Remote Desktop Management Interface (RDMI) standard
remedies that deficiency, enabling management products to share information across
multiple platforms and operating systems.
Apple Computer Inc., IBM Corporation, Ki NETWORKS Inc., and Sun Microsystems have
formed an alliance to implement a common agent technology, which facilitates collection
of network management information from hardware and software components from multiple
vendors. The common agent technology consolidates and synthesizes this information,
using existing management protocols including both SNMP and DMI. Common agent technology
permits DMI-enabled network components to be managed in an integrated fashion, and
provides existing management consoles with immediate access to DMI information. The
common agent technology is actually an SNMP implementation that supports integrated
management of DMI-compliant components and SNMP subagents. It is also capable of
converting DMI data into SNMP format. Consequently, network managers can support
both SNMP and DMI resources.
Network Management Products
Network management products operate on at least two levels. At the lower level,
a network management protocol must be in place to ferret out problems in the network.
These problems are then presented to the upper level, which collects and correlates
the information so it is understandable by humans (or application programs written
by humans). Generally speaking, the functions provided by network management products
include:
- Network status. Network management products enable the current state of
the network to be monitored. This includes showing which devices are online and which
are not, as well as the following information:
- Error reporting. If information is being corrupted in the network or devices
are not performing properly, these events will (or should) be reported with the status
information. Often, you can use this information to solve problems before they become
more serious.
- Performance. In the context of network management, performance normally
refers to line use. By showing the amount (percent) of usage on a line-by-line (or
controller-by-controller) basis, performance information enables you to review the
effectiveness of the network layout.
- Hard fault alarms. One of the primary purposes of network management products
is to provide an immediate alert in the event of a serious failure in the network.
To accomplish this, the product must detect and isolate the failure.
- Network modifications. Network management products provided by a vendor
for use on a specific type of computer often integrate the procedures for implementing
changes in the network under the large umbrella of network management. The theory
is that modifications to the network are important and directly affect the state
of the network, so the change procedures should be part of the network management
product. However, if the product is from a third party or is intended for use on
many different computer systems, this level of functionality will probably be absent.
In terms of the OSI Reference Model, network management functions are defined
by the Common Management Information Service (CMIS) and Common Management Information
Protocol (CMIP) standards. CMIS and CMIP were developed by the ISO as part of the
application-layer Network Management standards. In the context of network management
products, CMIP performs the lower-layer data collections functions and reports its
finding to CMIS.
Network management is one area where the demand has exceeded ISO's ability to
define stan-dards. Witness the increasing popularity of Simple Network Management
Protocol (SNMP). The SNMP definition facilitates the reporting and collection
of network errors. Originally targeted to bring network management tools to the TCP/IP
environment, SNMP provides functions similar to those in CMIP.
As a result of the decline in popularity of the OSI Reference Model (following
its de-emphasis by the U.S. government), the popularity of SNMP has increased in
the eyes of most ven- dors. From the manufacturer's perspective, SNMP represents
a relatively simple network management tool. Implementing SNMP involves having computers
and intelligent network devices report errors to SNMP and designating one or more
computers to receive the report of the errors collected from SNMP. Therefore, in
a multivendor network where some (or all) of the computers report to SNMP, a single
SNMP monitor station can track the network operations of several computer types.
End users appreciate that SNMP can be used in a multivendor environment.
There are many vendors in the world of network management, with each offering
its own sophisticated network management architecture. Note, however, that the architectures
are not mutually exclusive, and there are some advantages to running all three architectures
together. While the low end of the market is quite open and includes numerous products
such as ManageWise, a joint venture of Novell and Intel, the high end of the market
is largely dominated by HP, IBM, Cabletron Systems, and Sun Microsystems. The various
company approaches are explored in the following sections.
IBM SystemView/NetView
NetView is the network management element of IBM's systems management software,
SystemView. IBM has improved performance over older offerings by enabling CPU-intensive
GUI processes to be offloaded to client workstations.
In 1990, IBM's SystemView Series was never widely accepted, largely because it
depended on the OSI CMIP protocol at a time when SNMP was beginning to be more widely
used. Current versions of SystemView are unrecognizable when compared to the 1990
CMIP versions. IBM has now embraced SNMP as the de facto management standard of the
day, and has even embraced object technology in an attempt to make systems and network
management a little easier. While the earlier versions focused mainly on the mainframe
and SNA architecture, SystemView today is offered on four platforms: MVS, OS/400,
AIX, and OS/2. SystemView consolidates many systems and network management applications
into a single product; previously, IBM customers had to purchase management applications
separately.
In releasing the SystemView Series, IBM has acknowledged the growing trend toward
multi-vendor, client/server systems, and has given the product the ability to manage
resources from many different vendors. SystemView provides utilities for change and
configuration management, scheduling, workload balancing, storage and print management,
software distribution, systems administration, and many additional functions. Additionally,
its point-and-click interface and use of a process-oriented model marks a move towards
simplified and more integrated management.
Features of SystemView All four implementations of SystemView
support all of the systems management functions defined by the SystemView architecture,
which include business management, change management, configuration management, operations
management (includ-ing network management), performance management, and problem management.
Features include:
- Client Support. SystemView is able to manage clients including IBM OS/2,
HP-UX, Macintosh, NetWare, SCO UNIX, Sun Solaris, SunOS, Windows NT, and Windows
3.x.
- Storage Management. SystemView's Hierarchical Storage Management (HSM)
facility, part of the ADSTAR Distributed Storage Manager (ADSM) feature, automates
the process of moving infrequently used files to lower-cost storage media. HSM retains
files that are more frequently accessed on local file systems, which results in a
faster response time. With the HSM system, users access all files, regardless of
location, as if they were local.
- Data Management. The DataHub for UNIX Operating Systems data management
facility permits the administrator to manage multiple databases from a single control
point, and without having to know the different SQL syntaxes of the different databases.
- Change Management. Increasingly, mobile workers can cause the network
manager more than a few headaches. Change management is not a simple task, although
SystemView's Software Distribution for AIX facility offers significantly more automation
than previously available for this task.
- Performance Monitoring. The Performance Reporter facility tracks system
resources, such as disk utilization, and checks them against pre-set parameters.
- Remote Monitoring. The Nways Campus Manager Remote Monitor provides real-time
performance monitoring across a multivendor network.
SystemView for MVS SystemView for MVS, running on a System/390
MVS platform, permits the management of a distributed enterprise from a single control
point. SystemView for MVS is able to manage MVS, VM and VSE hosts, SNA and IP resources,
AIX and OS/400 systems, NetWare and other LANs, and several other network resources.
It combines more than 36 systems and network management applications, providing access
from a single, graphical window.
SystemView for OS/400 SystemView for OS/400 is a modular solution,
also controllable from a single point. Its Automation Center/400 application automates
the runbook, enabling the administrator to define important system conditions and
define actions to take automatically should those conditions occur. For managing
and analyzing performance data, the Performance Tools/400 application is included.
The System Manager/400 application is used to centrally manage distribution, operations,
software, and problems from a single AS/400 system.
SystemView for OS/2 The newest addition to the SystemView family,
SystemView for OS/2 is best used in small to medium-sized networks. It is based on
IBM's NetFinity product, and integrates NetFinity's features for hardware management,
inventory, file transfer, and more. Some of the features included in SystemView for
OS/2 include real-time monitoring, software process monitoring, performance monitoring
metrics, and a software inventory dictionary for automatically finding already-installed
applications. Also featured is support for DB2/2 and Lotus Notes, which can be used
to store and reuse configuration and performance data.
SystemView for AIX SystemView for AIX can manage an enterprisewide,
heterogeneous environment of multi-vendor devices and operating systems. Like the
other SystemView products, it manages the network from a single console. However,
the administrator can choose to share management functions and distribute some processes
from the server to client workstations. Operational tools include: the LAN Management
Utilities, for managing and monitoring IP, IPX, and NetBIOS devices; LAN Network
Manager for AIX, for viewing status information about the LAN; LoadLeveler, for job
management and balancing; and NetView for AIX, for managing multivendor TCP/IP networks.
NetView for AIX, the network management element of SystemView for AIX, supports
up to 30 operators who can share access to management functions. System access is
controlled through the distributed security features, and a sequential logon function
is included for seamless transfer of control from one operator to the next.
IBM's SystemView Advance Team program might ultimately result in even more integration
and features. This program invites third-party vendors to integrate their products
into the SystemView framework. The plan makes alliances with vendors offering network
and systems management products that support SystemView platforms. Members of this
team include Bay Networks, Boole and Babbage Inc. (San Jose, California), and Cisco
Systems Inc. (San Jose, California).
IBM and Tivoli
IBM has entered into an arrangement to acquire Tivoli Systems, a provider of systems
management software. The deal will bring Tivoli's innovative management technology
into IBM's family of systems management products, and will ultimately provide for
an even more comprehensive solution.
Cabletron Systems' SPECTRUM
Cabletron is positioning its SPECTRUM product as an alternative to products like
HP Open-View or IBM SystemView. SPECTRUM 3.1 runs on several operating systems, including
HP-UX (it is the only other network management system other than OpenView to run
on that platform). OpenView does not have a distributed architecture, which might
make SPECTRUM a better alternative for some sites. Cabletron is attempting to extend
SPECTRUM into the enterprise client/server arena with new systems management applications
that facilitate policy-based management. Besides Cabletron, several third-party companies
offer products that enhance the functionality of SPECTRUM with extra features such
as performance and capacity measurement and configuration management.
SPECTRUM is protocol-independent and uses an artificial intelligence technology
Cabletron calls Inductive Modeling Technology (IMT). Through IMT, SPECTRUM
can find solutions and solve problems on its own, with no human intervention. SPECTRUM
creates a model that pictures every single entity in the network, including cabling,
devices, topologies, and applications. The objects not only have intelligence about
themselves, but also about their relationships to other objects. Version 4.0 of SPECTRUM
gives the administrator the ability to manage not only the local domain, but any
network that has been configured by SPECTRUM--giving SPECTRUM enterprisewide capabilities.
HP OpenView
HP OpenView, like SystemView, is an integrated network and systems management
environment consisting of several related products. It is capable of managing NetWare
and Windows NT servers and PCs, and a large variety of server platforms. There are
a wide variety of third-party management solutions written for OpenView available
on several platforms, including HP 9000 systems, Sun Solaris workstations, and Windows
NT-based systems.
The HP OpenView Network Node Manager is at the center of OpenView. Network Node
Manager, a network management platform, provides a full view of the network through
TCP/IP and SNMP management. The utility runs the OpenView OSF/Motif interface, and
permits many tasks to be carried out with little or no programming. The Network Node
Manager includes the following subsystems:
- Event Browser. This subsystem permits event filtering and prioritization,
and enables the administrator to set and customize alarms and configure events on
a per-node basis.
- Discovery. This subsystem will automatically generate a map of a TCP/IP
network, monitor the status of network nodes, and discover devices across WANs.
- MIB Application Builder. This enables the administrator to create MIB
applications for MIB objects with no programming.
For larger networks, tasks can be distributed among several operators to reduce
the processing load on the management station. This is accomplished with the OperationsCenter
application, which offers manager-to-manager communications and hot-backup facilities,
two important steps towards increasing OpenView's overall scalability. By distributing
these tasks to up to 15 other operators, it becomes possible to manage a much larger
network through cooperative management of multiple domains. This application will
also offload much of the GUI processing from the server to operator consoles, thereby
freeing up the server for more management tasks.
The AdminCenter portion of OpenView provides configuration change management functions
for the enterprise. AdminCenter graphically displays the entire administration domain.
All network objects are discovered automatically, and their status is represented
with a color-coded schema.
HP entered into an alliance with Novell in 1996 to integrate its HP OpenView systems
management platform with Novell ManageWise. The alliance further opens up OpenView,
giving users of OpenView the ability to manage NetWare environments from the OpenView
framework.
HP is also making available its long-awaited Windows NT-based agents, extending
its reach further to the Windows world. The combination of NT and NetWare support
significantly expands the reach of OpenView and provides for a much more comprehensive
view of a multi-vendor enterprise. The Windows NT agent will also facilitate integration
between OpenView and Microsoft Systems Management Server.
HP is planning a number of enhancements to the OpenView for Windows platform to
enhance its PC management capabilities and bring the Windows version closer to the
UNIX implementation in terms of functionality. HP plans to add support for the DMTF's
Desktop Management Interface (DMI), thus enabling users to monitor the configuration
and inventory of desktop workstations. The DMI Browser facility will also permit
users to perform remote locking and booting. However, users will need two browsers:
one for monitoring SNMP MIBs and another for DMI MIFs.
Sun Microsystems Solstice SunNet
Manager
Sun Microsystems is following the same path as HP and IBM, and merging systems
and network management. In the past, a major complaint about Sun's management platform
was that it could not scale to very large networks. Sun has significantly expanded
its SunNet Manager over the past year with new implementations, including the Solstice
Site Manager for smaller networks and the Solstice Domain Manager for large or multiple
sites.
Solstice Enterprise Manager
The high-end version, Solstice Enterprise Manager, is still in the works--but will
be capable of managing in excess of 10,000 nodes. Sun Microsystems' recent alliance
with Computer Associates will ultimately produce a single product, meant to control
an entire enterprise network. The new product will combine CA's Unicenter systems
management and OpenIngres database, with Sun's Solstice SunNet manager network management
platform.
Site Manager can support a LAN of up to 100 nodes, and can report to Domain Manager,
which can handle up to 3,000 nodes. Site Manager and Domain Manager offer a consistent
interface and feature set, which makes it much easier to run both systems. Domain
Manager can be configured to receive information from multiple Site Managers, and
can also send and receive information to other Domain Managers. Site Manager can
access Novell's NetWare Management Agent (NMA) agent, which permits Site Manager
to access the NetWare server's file system and print queues, and other key attributes.
Domain Manager is available in one of three configurations: a standalone platform,
as a central manager where multiple Site Managers are connected to one or more Domain
Managers, and where multiple Domain Managers are interconnected as a cooperative
management platform. The ability to enable multiple Domain Managers to share information
gives the system a great deal of power and scalability; the Domain consoles can be
connected in a peer-to-peer fashion, thus permitting multiple administrators to share
the administration of the network.
By distributing the management processing load throughout the network, Solstice
Domain Manager is capable of handling a very large network. This is done through
one of two different types of agent technologies. The first agent directly accesses
managed objects, and the second is a proxy agent, which works as a middle
manager. The proxy agents communicate with the management platform through ONC/RPC,
translating the RPC protocol into a protocol that the managed element can understand.
This mechanism permits Domain Manager to control a large range of resources.
Three application program interfaces (APIs) are provided for building tools to
complement Domain Manager's functionality. These include the following:
- Manager Services API. This API provides ONC/RPC-based communication services
as an alternative to SNMP or OSI. These services permit both Domain Manager and Site
Manager to extend to other protocols, and scale well to large networks. This API
also provides access to Solaris' access control and authentication mechanisms.
- Agent Services API. This API is used to manage multiprotocol environments
through an intermediary protocol. A proxy agent can be written to this API, effectively
extending Domain Manager's reach even more.
- Database/Topology Map Services API. This API gives managers the means
to modify the management database and customize the topology display.
LAN Alternatives
While IBM's NetView is very effective in centralized networks and WANs, its applicability
to a LAN environment is less than ideal. In a LAN environment, all network activity
flows through the common LAN, and this LAN can be tapped and monitored, whereas in
central and WAN environments, there is no single common thread for communications.
In this LAN environment, multivendor equipment can operate multiple protocols
in the same physical network. At the lowest possible level, they all share the same
(or very similar) data link and physical interfaces. Thus, in a single network, the
Digital LAT protocol might run alongside HP's NS protocol, Digital's DECnet protocol,
TCP/IP, and Novell IPX, but they all use either the 802.2/802.3 frame definition
or the Ethernet frame definition. By focusing in on this lowest common denominator,
a LAN monitor can track all of these protocols and more.
This is the approach taken by Digital, HP, and Sun. All three provide products
to monitor the LAN operation at this low level. Thus, nonresponding addresses can
be detected, along with excessive retries or rejections. In addition to these low-level
functions, they also provide products to monitor their own specific protocols--so
Digital products monitor DECnet and LAT, HP products monitor NS, and Sun products
monitor TCP/IP.
Unfortunately, when a LAN extends into a WAN, these monitoring tools do not also
reach out into the wide area. Thus, in a WAN composed of multivendor equipment, multiple
products from multiple companies must be employed to track the network beyond the
LAN. Fortunately, as the use of WANs has begun to spread, so has the development
of comprehensive network management tools like SystemView. This remains a fast-paced
area of growth.
Centralized consoles, such as HP's OpenView and IBM's SystemView, are used in
the management of complex networks. However, these central consoles have not been
as useful as they could be for enterprise networks. The root of their problem is
scalability; the console gets bogged down when it reaches a certain number of devices.
Typically, after this threshold has been reached, an additional management console
must be added. Unfortunately, information is not shared between consoles. Intelligent
management agents (IMAs) and mid-level managers (MLMs) address this problem.
The IMA is able to act as an intelligent manager, diagnosing and repairing problems
as they occur. The MLM is similar, but is able to manage other agents. The IMA typically
resides in a managed device, while the MLM resides in the workstation and oversees
a certain domain within the network. The enterprise console then manages a group
of MLMs. The MLM sends summary reports to the enterprise console, so the console
is less likely to become overloaded. Cabletron Systems' SPECTRUM network manager
offers a good example of MLM features.
There are many obstacles to efficiently managing a network, particularly in a
multivendor environment. Hubs, routers, NICs, workstations, and servers might all
come from different companies.
Traditionally, network management products have come to run on UNIX platforms.
However, Microsoft's Windows NT is gaining recognition as an acceptable platform
for these critical applications. Several products, including SPECTRUM and Digital's
PolyCenter NetView, now support Windows NT.
Cabletron Focuses on Integration
Cabletron is also planning integration with Microsoft's System Management Server
(SMS). This integration will enable a SPECTRUM console to issue SMS commands; in
a future release of SPECTRUM, data sharing between the two will be permitted. Cabletron
has focused on ease of access in SPECTRUM 4.0, which will be able to send network
management reports to a Web server. This feature will enable anyone with a Web browser
and proper access to view management reports from any location.
The trend towards integration is being seen throughout the network management
industry. Novell Inc. (Provo, Utah) and Intel Corp. (Santa Clara, California) have
a new version of the ManageWise network management suite that better integrates the
two companies' management applications. ManageWise 2.0 combines separate consoles
for Intel's LANDesk and Novell's NetWare Management System. It integrates the NetWare
Directory Services (NDS) and unifies network management and administration for the
two management platforms. NDS maintains a central directory of authorized users,
and provides for a single point of administration for enterprises with multiple servers.
ManageWise 2.0 will also offer better SNMP support. Through ManageWise, an SNMP console
will be able to manage a NetWare server.
Products like SystemView and OpenView often work with third-party products to
expand their reach into other areas--such as a NetWare network. Novell's network
management products are supported by both IBM and HP; users of SystemView and OpenView
can gain immediate access to NetWare statistics through Novell's products.
Novell offers two network management products: LANalyzer for Windows and ManageWise.
LANalyzer is an inexpensive, software-only network analyzer meant for smaller
networks or for portable use. Running on an IBM 80386 processor, LANalyzer will continuously
monitor traffic on an Ethernet or token-ring segment, capture and decode NetWare
packets, and derive a variety of statistics such as bandwidth usage, traffic patterns,
and packet counts. However, because it can only monitor a single segment at a time,
it is usable only on smaller networks.
For managing multiple segments simultaneously, Novell offers their ManageWise
network management software. ManageWise is a more full-featured, integrated
set of management services that is used for controlling the network on an end-to-end
basis. Like LANalyzer, it manages Ethernet and token-ring networks running NetWare
3 or 4. It offers extensive standards support, including SNMP, IP, IPX, and RMON;
and several enhancements are available from third parties. IBM, SunSoft, and Hewlett-Packard
have all agreed to support ManageWise 2.0 in their own systems management offerings.
Novell takes the approach of offering network management as a network service,
integrated into the network itself, as opposed to presenting it as a centralized
system. ManageWise is installed on each NetWare server, and enables an administrator
to manage all NetWare servers from a single site. Because it is a distributed service,
it can take advantage of the processing power that exists on the network, and minimize
network traffic. Because ManageWise enables for shared access to the management information
it collects, multiple consoles can cooperatively manage a heterogeneous environment.
Users of IBM's SystemView can take advantage of the ManageWise network agent to get
a dynamic view of the NetWare topology directly from SystemView. Similarly, users
of HP's OpenView gain immediate access to NetWare statistics from the OpenView enterprise
console.
Version 2.0 of ManageWise permits managers to move easily between SNMP management
and NDS network administration. It uses NDS as a security measure for SNMP management
by enabling staff to authenticate managers on the network and restrict access to
management functions. ManageWise's SNMP agent technology permits NetWare servers
to be managed from any SNMP management console, and also makes its network mapping
services available to other consoles. Because it distributes its intelligent management
agents throughout the network, the need for continuous polling is kept to a minimum.
Remote Monitoring (RMON)
RMON technology makes management tasks that were previously available only
in the SNA environment possible for a distributed, internetworking environment. These
features in- clude network security, network design, and simulation. An embedded
RMON agent can be beneficial to the corporate network, as the number of interconnected
LANs and desktops continue to increase. RMON lends stability to the network, and
enables network managers to support more users and segments without incurring bandwidth
usage penalties. Most major internet-working vendors support embedded RMON, including
3Com (Santa Clara, Cailfornia), Bay Networks (Santa Clara, California), and Cisco
Systems (San Jose, California).
The RMON and RMON 2 standards were created to permit troubleshooting and diagnosis
of problems in an enterprise network, and to provide the means to proactively monitor
and diagnose a distributed LAN. In the RMON model, a monitoring device, known as
an agent or probe, monitors a network segment, gathers statistics,
and monitors for user-defined thresholds that, when exceeded, trigger an alarm. These
probes communicate via SNMP with a central management station. As networks get more
complex and far-reaching, standards such as RMON are becoming essential. The original
RMON 1 standard supported the monitoring of traffic only through the MAC (Data Link)
Layer of the OSI model, and was limited in its usefulness. RMON 1-based probes only
viewed traffic on the local LAN segment, and did not identify hosts beyond the router
level.
The RMON 2 standard supports the Network Layer and Application Layer as well,
making it usable for managing an enterprise network. The RMON 2 standard, however,
does not support high-speed LAN/WAN topologies, switched LANs, or monitoring of network
devices (the as-yet-undefined RMON 3 standard might accommodate these technologies).
RMON 2 still goes far beyond the previous specification in providing a more complete
view of network traffic, because the RMON groups map to the major Network Layer protocols,
such as IP, IPX, DECnet, Appletalk, Vines, and OSI.
The importance of Network Layer support is evident when looking at a distributed
environment, where resources might be on different physical LAN segments. These multiple
LAN segments might be connected by routers or switches. Any user, given the right
authorization by the administrator, can access any remote resource in the distributed
network. RMON 2-based products are available for deployment in switched internetworking
environments.
RMON can be used by managers to go beyond those functions afforded by SNMP for
network management, and can accommodate a much larger enterprise. SNMP is used to
configure and monitor network devices, but there are some limitations. SNMP management
software usually polls the software agents on a continual basis. As a result, there
is a finite amount of devices that can be monitored before the amount of traffic
reaches an unacceptable level. The IETF (Internet Engineering Task Force) Remote
Network Monitoring Management Information Base (RMON MIB) specification adds an extra
MIB that defines managed objects, using standard SNMP mechanisms. The RMON MIB is
mainly used to support monitors or probes that are not constantly connected to the
management software. The RMON MIB also diagnoses and logs events on network segments,
detects and reports error conditions, and expands SNMP's two-level hierarchy to provide
the network manager with more flexibility. A RMON monitor can send data to more than
one management application, and the alerts can be sent to the most appropriate station.
There are 10 basic RMON MIB groups, nine of which support Ethernet topologies
and the tenth reserved for parameters that are specific to token ring. The 10 groups
are:
- Statistics. This group shows data concerning network uses, traffic levels,
and other information for troubleshooting. It counts Ethernet or token-ring frames,
octets, broadcasts, multicasts, and collisions.
- History. Provides trend analysis of the data in the above Statistics group.
- Alarms. Permits thresholds to be configured, such that events can be triggered
when those thresholds have been exceeded.
- Hosts. Permits SNMP managers to receive information on network nodes that
lack SNMP agents.
- Host TopN. Permits reports to be defined, such that the top "n"
ranking hosts are listed for different variables. For example, a report can be generated
that shows the top "n" number of nodes that generated a specific number
of errors over a time period.
- Traffic Matrix. Permits a matrix that cross-references destination addresses
against source addresses, and plots values for frames, octets, and errors for each
traffic pattern. This permits the manager to discover which conversations generate
the most traffic or errors.
- Filters. Enables the manager to define packet match conditions to capture
relevant data for analysis.
- Packet Capture. This group provides capture buffers to hold information
derived from actions taken by the Filters group. Captured packets are used by several
network analysis software tools, such as Novell's LANalyzer.
- Events. Generates an events log.
- Token Ring. Actually several groups rolled into one, the Token Ring group
includes token-ring-specific functions, such as ring station order and source routing.
Large token-ring internetworks often must be managed with minimal management and
monitoring tools, simply because of limited availability. Token-ring RMON represents
a standards-based approach to managing a token-ring LAN. However, many of the existing
token-ring probes lack support for token-ring-specific features, such as autosensing
ring speed or the ability to stop beaconing after a number of unsuccessful insertion
attempts. There are also, of course, bandwidth issues to consider. The RMON management
application accesses the RMON probes through in-band SNMP functions, which means
that the bandwidth consumption of information requests can be a major consideration.
Major vendors of RMON products include Armon Networking (Santa Barbara, California),
Frontier Software (Tewksbury, Massachusetts), and Hewlett-Packard (Palo Alto, California).
In terms of the OSI model, RMON 2 supports Layer 1 (Physical), Layer 2 (Data Link),
Layer 3 (Network), and Layer 7 (Application). Most RMON products, however, do accommodate
all seven layers, although support for the Transport, Session, and Presentation layers
are not yet standardized and are implemented through proprietary extensions.
RMON Agents
Both 3Com Corp. and Cisco Systems Inc. have plans for offering RMON agents that pass
data to RMON management applications. The agents will be built into the companies'
switches as a standard feature. RMON agents send data from each port on a switch
to a management application. The agents perform the same task as RMON probes, which
are attached to the links between switches, although the stand-alone probes are a
more costly solution.
Frontier Software has created a superset of RMON 2, known as EnterpriseRMON,
that overcomes the limitations of RMON 2 and supports all seven layers of the OSI
model. Frontier's NETscout further extends RMON by supporting switched LANs
and high-speed LAN/WAN topologies. (In the future, Frontier is also planning on adding
support for Fast Ethernet and ATM.) The ability to monitor LAN switch and interswitch
traffic permits NETscout to manage a virtual LAN (VLAN) environment. A NETscout probe
device can be managed from any RMON-compliant management software product; similarly,
the NETscout Manager application can manage any RMON probe.
VLAN (Virtual LAN) Technology
VLANs represent software-defined groups of endstations that communicate
as though they were physically connected. The end stations can, however, be located
on different segments throughout the greater network. VLANs also carry the advantage
of allowing for policy-based management, which permits the network manager to assign
priorities to different types of traffic. This model permits the network manager
to manage the network from a business perspective, instead of a purely technical
one. The network manager would, under this paradigm, be able to establish policies
that would limit the amount of time a user could be on the net-work, the amount of
bandwidth each user would have access to, and which applications are accessible.
The logical grouping of VLANs make it easier to do moves and changes, and provides
for better use of bandwidth. One of the biggest problems of VLAN technology has been
lack of interoperability. Cisco Systems is addressing this problem by spearheading
a standard that could be used to create multivendor VLANs. The lack of interoperability
has, until now, meant that in order to deploy VLAN technology, a company must stay
with a single vendor. Several other networking vendors are supporting the standard
(the IEEE 802.10 Interoperable LAN/MAN Security standard) as a way to build multivendor
VLANs.
IEEE 802.10, Cisco, and VLANs
IEEE 802.10 was originally created to address security within a shared LAN environment.
Under Cisco's plan, the spec does not have to be modified to apply to VLANs. Cisco
proposes that 802.10 be used in routers and switches for identifying network traffic
that belongs to specific VLANs. Cisco supports 802.10 in its own routers.
The IEEE 802.10 Interoperable LAN/MAN Security standard would be used as a way to
identify VLANs by tagging frames for delivery to different VLAN segments. However,
a method for sharing address data still must be defined. Cisco proposes that a 4-byte
field in the 802.10 frame be used to hold VLAN ID data; that field was originally
intended to carry security information. Network hard-ware from multiple vendors would
then be interoperable because they would all be able to send frames to different
VLAN segments.
VLAN technology could potentially add a great deal of flexibility and security
to a network, and save a tremendous amount of time and money (not to mention headaches).
In a large, increasingly mobile enterprise, managers must spend an increasingly high
percentage of their time accommodating moves, additions, and changes. The VLAN model
would significantly reduce the time spent on these tasks, and enable users to move
more freely between logical LANs.
Switches must also be able to share address table data, and there are no proposals
for how switches could exchange frame information. Management is another issue of
VLAN inter-operability that needs to be addressed. There have been no definitions
laid out for VLAN management objects, and all switches have different proprietary
MIBs.
Most VLAN systems require users to define the VLAN based on LAN segments or Media
Access Control (MAC) addresses. Although VLANs simplify management, one major limitation
that existed until recently is that the manager had to issue new IP addresses manually
whenever a new VLAN is established. More recent developments permit a single station
running multiple protocols to belong to multiple VLANs. This technology creates virtual
workgroups based on protocol type or subnetwork address, and requires less configuration
on the part of the network manager.
The enterprise-wide VLAN is destined to become a reality, due in part to IBM's
Switched Virtual Network architecture. This architecture provides a definition for
grouping users over an ATM backbone using software, on its Nways switches and hubs.
For more information about virtual LANs, see the "LAN Emulation" section
in Chapter 12, "High-Speed Networking."
Managing Mobile Computers
Businesspeople carrying laptops to their homes and with them on business trips
have become a common sight. These traveling road warriors often have the ability
to dial into the corporate network to access applications, data, and critical corporate
information. However, for the network manager, this increased mobility brings new
challenges.
The MMTF
How do you manage something that is only occasionally connected and has no fixed
geographic location? The Mobile Management Task Force (MMTF) might have the
answer. The MMTF was organized to create extensions to SNMP 2, which would permit
network managers to troubleshoot and control mobile clients using low-bandwidth remote
or wireless links.
A proposed SNMP agent will provide for better network administration over mobile
users. The MMTF has proposed a specification for a mobile Management Information
Base (MIB) extension for TCP/IP networks. This MIB will permit SNMP consoles gather
configuration and location data from dial-in devices.
Wireless Communications
Wireless is not likely to ever replace traditional wired networks, but there are
areas where it can be useful. Wireless is not suitable for a data-intensive corporate
environment, but might make sense for temporary connections, shop-floor applications,
or in other situations where wiring might not be practical. Most wireless LANs send
data much slower than standard 10 Mbps Ethernet--usually at about 1 or 2 Mbps, although
frequency-hopping can speed up the throughput somewhat. The three types of wireless
systems are: Wireless LANs, which establish a link within a limited area,
such as a building; wireless remote bridges, which connect buildings within
a 25-mile range; and nationwide WANs, which can maintain a connection between
a large mobile workforce.
Commercial IP software products are starting to appear that enable mobile PC users
to keep a wireless network connection over multiple segments in a large TCP/IP network.
With such a system, proprietary protocols are no longer required for large wireless
networks. Typically, if a user moves between segments, the wireless connection gets
dropped. Users on multi-campus networks often are required to restart their hardware
because of this limitation.
Mobile IP
IP6, currently under development by the IE T F, includes specifications
for mobile IP that will enable mobile users to maintain these types of connections
more efficiently. Under this draft, a mobile node will always be identified by a
fixed home address, regardless of where it is physically plugged into the Internet.
The remote node will have a "care of" address that specifies the current
location. Packets addressed to the fixed home address will be transparently routed
to the "care of" address.
Of the many types of wireless technologies, Cellular Digital Packet Data (CDPD)
technology holds perhaps the greatest potential, although it has not been widely
deployed. CDPD technology sends data over a cellular network that is already being
used for voice transmission; as such, it does not require establishing an entirely
new infrastructure. It sends data packets between voice transmissions on an existing
cellular channel without having any negative impact on the voice communication. The
packets merely fill up unused voice spaces in a cellular transmission. The CDPD standard
is non-proprietary, and allows existing applications to be adapted to the wireless
environment. It supports multiple protocols, including IP, and uses cellular telephony
standards already in use by cellular telephone users.
CDMA
Code Division Multiple Access (CDMA) is another emerging digital wireless
technology that promises improved call quality and new wireless features. (The key
word here, as in all wireless technologies, is "emerging.") Like CDPD,
CDMA holds great potential in promoting open wireless standards, and ultimately more
widespread commercial acceptance of wireless services. A new industry group, the
CDMA Development Group (CDG), plans to address international development of CDMA
standards, which will eventually permit wireless systems in all countries to interoperate.
Security and Firewalls
The move to open computing and client/server architectures has brought a great
many advantages, but administering security has become a greater problem than ever
before--especially in situations where the corporate network is connected to the
public Internet. For example, by itself, TCP/IP has no inherent security. Many a
worried administrator has spent more than a few sleepless nights wondering when the
next hacker will wander into his domain.
Firewall products enforce strict control over access to the network, usually taking
the approach of denying any type of access that is not expressly permitted. However,
although these tools might keep hackers at bay, they might also keep legitimate users
from taking full advantage of technologies that might otherwise be at their disposal--such
as streaming video.
Proxy servers, on the other hand, will permit access to all Internet resources
while still maintaining security. Under this type of system, a command is executed
to an HTTP proxy server running on a separate firewall machine. The proxy takes requests
and executes them, requesting whatever information is required from outside remote
servers, and then delivers the response to the protected machine. A proxy server
can also retain a cache of data, which returns requested documents more quickly.
Because the data is then stored locally, it is available immediately, and the proxy
does not have to go out and look for it each time it is requested. Caching is done
usually on the proxy server, rather than the local client. Although proxy software
is widely available, each protocol requires its own proxy server, which means a lot
of administrative overhead.
IPSec
As previously mentioned, TCP/IP has no inherent security of its own. A proposed IETF
security standard, IPSec (Internet Protocol/Security), will be appearing in firewall
and TCP/IP stacks soon. IPSec is not specifically mandated for the next version of
TCP/IP, version 6, although it will work with both version 6 and the current iteration.
The other type of firewall is a simple packet-filtering router, which decides
whether to forward a packet based on the IP address and TCP port number in the packet
header. These are much less secure than proxy server solutions, but are more transparent
to the end user.
The Security Administrator Tool for Analyzing Networks (SATAN), a security
tool designed by Dan Farmer, stirred up some controversy when Farmer decided to make
it freely available on the Internet. SATAN detects vulnerabilities in networks, and
can be a valuable tool that helps administrators find their networks' weak spots.
However, it can also be used by a hacker to find the network's weak spots.
The application can be valuable to the administrator who runs it, reads the report
of vulnerabilities, and fixes all the holes. If the administrator does so first,
any hacker that subsequently applies SATAN to the network will come up empty-handed.
SATAN is easy to use, although its intuitiveness is a double-edged sword. First-time
hackers with little experience can easily break into a system, and the report clearly
describes any vulnerabilities and tells how to fix them.
If you're worried about an outside SATAN attack, get a copy of Gabriel,
a free SATAN detector that warns administrators of network intrusion.
© Copyright, Macmillan Computer Publishing. All
rights reserved.
|
