A Global Manufacturing Company
The large manufacturing company depends upon its mission-critical IP backbone to communicate between hundreds of sites located all over the world. To deploy an NNM system at each physical site wouldn’t be cost effective so you select 30 sites with local network support staff instead. Each site will receive a collection station and two sites will receive a management station. Most of the NNM user community accesses their NNM systems using an X-Windows emulator running on their Windows systems. A few users prefer Macintosh computers running MacX, or Linux systems running their built-in X-Windows software. The system administrators use the built-in X-Windows software in their UNIX workstations to access remote NNM systems.
The NNM systems are staged at the corporate IT department and shipped to their destinations according to a schedule. Each system is loaded with the current version of the OS, the appropriate OS patches, NNM and its current patches, and third-party bolt-on applications with their current patches. Since these are UNIX systems, they are configured as NIS+ replicas that contain all user account information. It is intended that each site be able to access another’s NNM system for support and backup purposes.
When the NNM system is physically installed at the destination site, its network configuration is preconfigured and the system immediately sends an e-mail message to the system administrator when it boots for the first time. At this point there is no seedfile configured. NNM’s initial management domain is the local subnet only. All that remains is for the central IT staff to work with the local map builders to refine the management domain for the site and build up the seedfile accordingly. Usually, the site’s discovery filter is modified to allow discovery of site-specific equipment, such as mission-critical servers, but the standard corporate discovery filter only allows for network equipment such as routers, switches, and hubs.
The local network support staff frequently wants to make small changes to their NNM system that would require root access to the seedfile and filters file. Since root access is strictly limited to system administrators, and since the UNIX skills possessed by the staff varies, a small GUI is written for them that allows viewing and modifying the data without requiring direct access to the files. This is a good example of how an NNM-trained developer can help implement additional functionality.
The central IT system administrator can manage all remote NNM systems using the standard X-Windows interface. If WAN performance issues limit using X-Windows, a simple low-overhead telnet session can be used. Should the UNIX system suffer a hard crash, a terminal server is cabled to a serial port to allow direct access to the diagnostic port. The system is shipped with a bootable CD-ROM in the CD tray as an alternate boot device.
Each NNM system executes a VNC (virtual network computing) session and maintains a read/write ovw session with the map. The system and NNM administrators can attach to this VNC session for map maintenance purposes.
Each collection station is configured to export subnets and routers to each of the two management stations. For such a large IP network, it is neither practical nor cost-effective to export more of the site topology. Each management station operates independently, although the Internet submaps are kept identical so that each station can act as a backup for the other.
Each NNM system performs its own scheduled backup and transmits the backup file to a central repository at the corporate IT site. The backup script automatically e-mails the backup log to the system administrator.