📄 ch11.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<SCRIPT LANGUAGE="JavaScript">
<!--
function popUp(pPage) {
var fullURL = document.location;
var textURL = fullURL.toString();
var URLlen = textURL.length;
var lenMinusPage = textURL.lastIndexOf("/");
lenMinusPage += 1;
var fullPath = textURL.substring(0,lenMinusPage);
popUpWin = new Object() ;
figDoc= popUpWin.document;
zhtm= '<HTML><HEAD><TITLE>' + pPage + '</TITLE>';
zhtm += '</HEAD>';
zhtm += '<BODY bgcolor="#FFFFFF">';
zhtm += '<IMG SRC="' + fullPath + pPage + '">';
zhtm += '<P><B>' + pPage + '</B>';
zhtm += '</BODY></HTML>';
window.popUpWin.document.write(zhtm);
window.popUpWin.document.close();
// Johnny Jackson 4/28/98
}
//-->
</SCRIPT>
<META NAME="Author" Content="Steph Mineart">
<TITLE>Managing Multivendor Networks -- Ch 11 -- Network Management</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF">
<!--#exec cmd="/www/docs/ssi-bin/restricted_search.ssi"-->
<!--#exec cmd="/www/docs/ssi-bin/inc.ssi"-->
<CENTER>
<H1><IMG SRC="que.gif" tppabs="http://docs.rinet.ru:8080/MuNet/button/que.gif" WIDTH="171" HEIGHT="66" ALIGN="BOTTOM" BORDER="0"><BR>
<FONT COLOR="#000077">Managing Multivendor Networks</FONT></H1>
</CENTER>
<CENTER>
<P><A HREF="ch10.htm" tppabs="http://docs.rinet.ru:8080/MuNet/ch10/ch10.htm"><IMG SRC="previous.gif" tppabs="http://docs.rinet.ru:8080/MuNet/button/previous.gif" WIDTH="128" HEIGHT="28"
ALIGN="BOTTOM" ALT="Previous chapter" BORDER="0"></A><A HREF="ch12.htm" tppabs="http://docs.rinet.ru:8080/MuNet/ch12/ch12.htm"><IMG
SRC="next.gif" tppabs="http://docs.rinet.ru:8080/MuNet/button/next.gif" WIDTH="128" HEIGHT="28" ALIGN="BOTTOM" ALT="Next chapter"
BORDER="0"></A><A HREF="index-2.htm" tppabs="http://docs.rinet.ru:8080/MuNet/index.htm"><IMG SRC="contents.gif" tppabs="http://docs.rinet.ru:8080/MuNet/button/contents.gif" WIDTH="128"
HEIGHT="28" ALIGN="BOTTOM" ALT="Contents" BORDER="0"></A>
<HR>
</CENTER>
<CENTER>
<H1><FONT COLOR="#000077">- 11 -<BR>
Network Management</FONT></H1>
</CENTER>
<UL>
<LI><A HREF="#Heading1">The Problems of Problem Determination</A>
<UL>
<LI><A HREF="#Heading2">Problem Determination: Centralized Networks</A>
<LI><A HREF="#Heading3">Problem Determination: LANs</A>
<LI><A HREF="#Heading4">Problem Determination: WANs</A>
</UL>
<LI><A HREF="#Heading5">Approaches to Network Management</A>
<LI><A HREF="#Heading6">Network Management Products</A>
<UL>
<LI><A HREF="#Heading7">IBM SystemView/NetView</A>
<LI><A HREF="#Heading8">Cabletron Systems' SPECTRUM</A>
<LI><A HREF="#Heading9">HP OpenView</A>
<LI><A HREF="#Heading10">Sun Microsystems Solstice SunNet Manager</A>
<LI><A HREF="#Heading11">LAN Alternatives</A>
</UL>
<LI><A HREF="#Heading12">Remote Monitoring (RMON)</A>
<LI><A HREF="#Heading13">VLAN (Virtual LAN) Technology</A>
<LI><A HREF="#Heading14">Managing Mobile Computers</A>
<LI><A HREF="#Heading15">Wireless Communications</A>
<LI><A HREF="#Heading16">Security and Firewalls</A>
</UL>
<P>
<HR SIZE="4">
</P>
<P>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.
<H2><A NAME="Heading1"></A><FONT COLOR="#000077">The Problems of Problem Determination</FONT></H2>
<P>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).</P>
<P>Today's networking picture is much larger and more complicated. Simple coaxial-based
LANs now interface with fiber-optic <I>metropolitan area networks (MANs)</I> 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.</P>
<P>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.</P>
<P>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.
<H3><A NAME="Heading2"></A><FONT COLOR="#000077">Problem Determination: Centralized
Networks</FONT></H3>
<P>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).</P>
<P><A HREF="javascript:if(confirm('http://docs.rinet.ru:8080/MuNet/ch11/11fig01.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/11fig01.gif'" tppabs="http://docs.rinet.ru:8080/MuNet/ch11/11fig01.gif"><B>FIG. 11.1</B></A> <I>Points of Failure in Point-to-Point
and Hierarchical Networks</I></P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P>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.
<H3><A NAME="Heading3"></A><FONT COLOR="#000077">Problem Determination: LANs</FONT></H3>
<P>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.</P>
<P><A HREF="javascript:if(confirm('http://docs.rinet.ru:8080/MuNet/ch11/11fig02.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/11fig02.gif'" tppabs="http://docs.rinet.ru:8080/MuNet/ch11/11fig02.gif"><B>FIG. 11.2</B></A> <I>Examples of Ring, Star, and Bus
Networks</I></P>
<P>In a token-passing <I>ring network</I> (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).</P>
<P>In a <I>star network,</I> 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.</P>
<P><I>Bus networks</I> 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.</P>
<P>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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -