Managing Multivendor Networks -- Ch 11 -- Network Management

Managing Multivendor Networks

- 11 Network Management
The Problems of Problem Determination Problem Determination: Centralized Networks Problem Determination: LANs Problem Determination: WANs Approaches to Network Management Network Management Products IBM SystemView/NetView Cabletron Systems' SPECTRUM HP OpenView Sun Microsystems Solstice SunNet Manager LAN Alternatives Remote Monitoring (RMON) VLAN (Virtual LAN) Technology Managing Mobile Computers Wireless Communications Security and Firewalls 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.
file:///F|/Books/book-121/ch11.htm[10/9/2012 9:25:35 PM]

Managing Multivendor Networks -- Ch 11 -- Network Management

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 welldefined 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.

file:///F|/Books/book-121/ch11.htm[10/9/2012 9:25:35 PM]

Managing Multivendor Networks -- Ch 11 -- Network Management

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

file:///F|/Books/book-121/ch11.htm[10/9/2012 9:25:35 PM]

Managing Multivendor Networks -- Ch 11 -- Network Management

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
file:///F|/Books/book-121/ch11.htm[10/9/2012 9:25:35 PM]

Managing Multivendor Networks -- Ch 11 -- Network Management

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 protocollevel 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

file:///F|/Books/book-121/ch11.htm[10/9/2012 9:25:35 PM]

Managing Multivendor Networks -- Ch 11 -- Network Management

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.
file:///F|/Books/book-121/ch11.htm[10/9/2012 9:25:35 PM]

Managing Multivendor Networks -- Ch 11 -- Network Management

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

file:///F|/Books/book-121/ch11.htm[10/9/2012 9:25:35 PM]

Managing Multivendor Networks -- Ch 11 -- Network Management

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 lowercost 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 realtime 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 multivendor 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

file:///F|/Books/book-121/ch11.htm[10/9/2012 9:25:35 PM]

Managing Multivendor Networks -- Ch 11 -- Network Management

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.

file:///F|/Books/book-121/ch11.htm[10/9/2012 9:25:35 PM]

Managing Multivendor Networks -- Ch 11 -- Network Management

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.

file:///F|/Books/book-121/ch11.htm[10/9/2012 9:25:35 PM]

Managing Multivendor Networks -- Ch 11 -- Network Management

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.

file:///F|/Books/book-121/ch11.htm[10/9/2012 9:25:35 PM]

Managing Multivendor Networks -- Ch 11 -- Network Management

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

file:///F|/Books/book-121/ch11.htm[10/9/2012 9:25:35 PM]

Managing Multivendor Networks -- Ch 11 -- Network Management

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 userdefined 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
file:///F|/Books/book-121/ch11.htm[10/9/2012 9:25:35 PM]

Managing Multivendor Networks -- Ch 11 -- Network Management

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

file:///F|/Books/book-121/ch11.htm[10/9/2012 9:25:35 PM]

Managing Multivendor Networks -- Ch 11 -- Network Management

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

file:///F|/Books/book-121/ch11.htm[10/9/2012 9:25:35 PM]

Managing Multivendor Networks -- Ch 11 -- Network Management

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.

file:///F|/Books/book-121/ch11.htm[10/9/2012 9:25:35 PM]

Managing Multivendor Networks -- Ch 11 -- Network Management

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.

file:///F|/Books/book-121/ch11.htm[10/9/2012 9:25:35 PM]