 referring to the vendor of the device in question. Transactions between an NMS and managed device are usually made where the NMS makes a request and the managed device responds. This strategy works when the NMS periodically obtains management information on a "must know immedi- ately" basis. Under certain conditions, the managed device must inform the NMS of management information, such as in the case of faults or alarms. There is also the option of the NMS periodically polling all devices for fault and alarm information, but this is undesirable for the following reasons: Latency/delay can be considerable and increases proportionally with the number of devices being polled on the network. The effect would be to overload the network with management traffic for the polling of devices which, more than 95% of the time, have no valuable informa- tion to provide. Hence the ability to inform the NMS of traps is distributed, with managed objects being capable of sending traps as and when they arise. In order to receive the incoming traps to the specified port, and to view and parse traps, the MibBrowser has a Trap Viewer. The Trap Viewer can listen to one or more ports at a time and the traps can be sent to the Trap Viewer from any host (see Figures 4.9 and 4.10). 4 Network Management Using SNMP TrapViewer Class Source Message Clear 192.168.1.215 6/26/2001 18:22:16 1.3.6.1.2.1.1.4.0: STRIN Clear 192.168.1.215 6/26/2001 18:22:18 1.3.6.1.2.1.1.4.0: STRIN Clear 192.168.1.215 6/26/2001 18:22:20 .1.3.6.1.2.1.1.4.0: STRIN Clear 192.168.1.215 6/26/2001 18:22:23 1.3.6.1.2.1.1.4.0: STRIN TrapList 162:public Community public TrapParser Start Trap Details Delete Trap ParserEditor Status: Listening for Traps Figure 4.9 Trap Viewer providing summary trap information. Trap Details TimeStamp 0 hours, 0 minutes, 10 seconds. Enterprise iso.org.dod.internet.mgmt.mib-2.12 Generic Type Specific Type Message Severity Clear Entity mnahesh/192.168.1.50 RemotePort Community public 192.168.1.48 Source 192.168.1.48 TimeReceived 7/19/2001 15:47:4