Where The Read/Write Map Is Displayed

When no one is looking at the network map, is NNM still monitoring the network? Of course! The NNM daemons are always running in the background. The netmon daemon in particular continues to poll all managed devices for status and configuration. The snmpCollect daemon continues to collect SNMP data. The event subsystem continues to collect events, traps, and to react to configured actions. The database is continually updated as netmon discovers new objects and as nodes that are down too long are deleted. The maps are another matter.

You’ve noticed that every time you launch ovw, a map synchronization occurs. Look closer and you will see ovw remove icons, add new ones, and change the status of others. Map synchronization takes only a few seconds if the map was recently closed, but it can take a great deal of time if the map hasn’t been open for days. The synchronization process lets ovw update the map database with the aid of ipmap. All events that occurred since the last time the map was open must be processed to ensure the map is up to date. Note that as long as a read/write copy of a map is open, it is updated dynamically as network events take place. Therefore, a read/ write copy of all operational maps should be kept open to keep them current.

Now a read/write map is an editable map, too. Clearly, only the map builders should have read/write access to operational maps, and all other users should open read-only copies of maps. The map builders are the owners of their maps, so by default operational users can only open them in read-only mode. So far, so good. But if the read/write map is not open, then the read-only maps won’t get topology updates. One disadvantage of read-only maps is that their users can’t take a map snapshot, for which read-write access is required. Read-only maps do get status updates because status can be changed without a map being writable. OK, so this means you need to keep a copy of all writable operational maps open all the time, in a safe place. The map builder still makes any necessary changes at one time or another, possibly on an ad-hoc basis or at scheduled times.

This discussion assumes that NNM is running in a multiuser environment with remote X-Windows or the web as the primary access to the map. It’s not necessarily applicable to a small Network Operations Control Center (NOCC) with a single dedicated management workstation and on-site-only access requirements.

Where is a safe place to keep read/write operational maps open? A safe place is important because you don’t want a read/write map ovw session locking up or terminating for any reason, whether caused by equipment failure or interference from carbon-based units. Here’s a list of some possible display locations:

• the map builder’s workstation

• a dedicated network X-terminal that nobody accesses

• the NNM console located in a secure location

• the virtual network computing (VNC) console

Given that network management is a 24x7x365.23 ^[1] operation, it’s clear that the map builder’s workstation is not an appropriate location to display the read/write operational maps. Map builders don’t spend the day focusing on just maps, their workstations will be used for other activities; an occasional workstation reboot might be necessary, and even map builders have been known to take vacations.

^[1] This is why we have leap years, remember?

An X-terminal (for the UNIX version of NNM) dedicated to display the read/write maps would be acceptable. This X-terminal could be any of the following:

• a Windows machine running an X-terminal emulator such as Exceed from Hummingbird or Reflection/X from Walker-Richer-Quinn (WRQ)

• a real X-terminal

• a UNIX workstation (for which X-Windows is the standard GUI) such as a RISC HP-UX computer or an Intel-based computer running Red Hat Linux

• a Macintosh running an X-terminal emulator such as MacX from Apple

• any other computer capable of running X-Windows

The dedicated X-terminal can be located in a network operations and control center (NOCC) in plain sight with the screen locked but not covered. The actual submap displayed would be the one showing the management domain for which the NOCC is responsible.

Another alternative is to display the read/write maps on the console of the NNM system which also runs X-Windows. The display should be locked, but not covered, to prevent interference with the ovw sessions. Since the NNM system is available 24x7x365.23, it’s an excellent choice. The downside is that the display and keyboard cannot be used operationally, which wastes this resource.

Displaying the read/write maps on the virtual network computing (VNC) console may be the best solution. A VNC can simulate an X-terminal on the UNIX system, so it’s always running. To gain access to it, use the vncview command, supply a password, and a copy of the VNC display is sent to a large window on your X-terminal display. It’s fully interactive. This allows the map builder to attach to the VNC and make map changes at any time of the day or night. The user updates the affected read-only map using the Map:Refresh pulldown menu.

VNC was developed by AT&T laboratories. To learn more about this free, unsupported, cross-platform software see the FAQ at:

http://www.uk.research.att.com/vnc/Faq.html

The NNM system administrator will have to write a small shell script that runs at boot time to bring up the VNC environment and launch ovw sessions with read/write maps. ITO or a similar tool should monitor these ovw sessions to ensure they are always running.

The map builder might need to terminate a remote read/write ovw session in order to open a read/write map for editing purposes. The appropriate steps for doing this as safely as possible using NNM 5.x are:

• use ovwlistsessions to get the session ID for the read/write map
  
  
• use ovsession -k ID to gracefully terminate the session
  
  
• if ovw won’t terminate, determine its process ID (PID) and issue a graceful kill -15 PID or a brutal kill -9 PID as necessary
  
  
• issue $OV_BIN/ovw -rw -map map_name to edit the map
  
  

For NNM 6.x, HP recommends ovuismpd be used. Use ovstatus -v ovuispmd to list the active ovw sessions and ovstop -c ovuispmd to gracefully terminate all of them at once. Use ovstart ovuispmd to allow users to invoke ovw again. Note that ovpause causes ovspmd to pause ovuispmd, suspending the active ovw sessions. Finally, ovresume causes ovspmd to start ovuispmd, resuming suspended ovw sessions.