ch11.htm

this describes managing multivendor networks

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.</P>
<P>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.</P>
<P>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.</P>
<P>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.
<H3><A NAME="Heading4"></A><FONT COLOR="#000077">Problem Determination: WANs</FONT></H3>
<P>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.</P>
<P>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.</P>
<P><A HREF="javascript:if(confirm('http://docs.rinet.ru:8080/MuNet/ch11/11fig03.gif  \n\nThis file was not retrieved by Teleport Pro, because it was redirected to an invalid location.  You should report this problem to the site\'s webmaster.  \n\nDo you want to open it from the server?'))window.location='http://docs.rinet.ru:8080/MuNet/ch11/11fig03.gif'" tppabs="http://docs.rinet.ru:8080/MuNet/ch11/11fig03.gif"><B>FIG. 11.3</B></A> <I>Sample WAN</I></P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P>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).</P>
<P>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.</P>
<P>Given these large networks and the complex problems they pose, the need for network
diagnostic equipment and software should be obvious.
<H2><A NAME="Heading5"></A><FONT COLOR="#000077">Approaches to Network Management</FONT></H2>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P><I>Breakout boxes</I> 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.</P>
<P>In contrast, data communications <I>line monitors</I> 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.</P>
<P><I>LAN monitors</I> 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.</P>
<P>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.


<BLOCKQUOTE>
	<P>
<HR>
<B><font color=#000077>NOTE:</font> </B>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. 
<HR>


</BLOCKQUOTE>

<P>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.</P>
<P>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).</P>
<P>In TCP/IP networks, you do have one other important diagnostic tool: the <TT>ping</TT>
command. The <TT>ping</TT> 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.</P>
<P>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.</P>
<P>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.</P>
<P>The <I>Desktop Management Interface (DMI),</I> a standard promoted by the <I>Desktop
Management Task Force (DMTF),</I> 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 <I>Management
Information Format (MIF) database,</I> 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.</P>
<P>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 <I>management information base (MIB)</I>.</P>
<P>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 <I>Remote Desktop Management Interface (RDMI) standard</I>
remedies that deficiency, enabling management products to share information across
multiple platforms and operating systems.</P>
<P>Apple Computer Inc., IBM Corporation, Ki NETWORKS Inc., and Sun Microsystems have