|
|
|
|
SNMP is a commonly supported management protocol for most routers and switches. It is a simple protocol where a management system (such as Traverse) queries devices (such as routers and switches) for metrics, and the devices respond with the values for the queried metrics. Traverse supports all versions of SNMP (v1, v2c and v3) and has a very efficient polling engine which reduces network traffic further by multiplexing multiple queries to a host in a single packet.
SNMP v1 and v2
To monitor an SNMP device using version 1 or 2c, all that is required is the correct SNMP community string which will allow querying the remote host. This community string (by default set to public) is specified on the Device Management page in Traverse. Keep in mind that most modern devices have access control lists which restrict which hosts can query it using SNMP. If such a list exists, you must enable access for the Traverse host. See Installing SNMP Agents , for details on installing SNMP agents on specific hosts.
SNMP v3
SNMP version 3 has extended security features built in which require additional configuration. Instead of a community string, SNMP v3 has a username and an optional password, and an optional data encryption option. In Traverse, you would specify these SNMP v3 parameters by setting the community string field as follows:
username : password : encryption_phrase
Example:
myUser:myPassword:encryptMe
You can then select if the password should be encrypted using MD5 or SHA1 (it must be at least 8 characters long). You can also select from one of the data encryption types of None, DES or AES.
SNMP MIB
Information in SNMP is organized hierarchically in a Management Information Base (MIB). The variables in the MIB table are called MIB objects, and each variable represents a characteristic of the managed device. Each object in the MIB table has a unique identifier, called an Object ID (OID), and these are arranged in a hierarchical order (like in a tree).
The standard MIB variables typically start with the OID prefix of "1.3.6.1.2.1" which translates as follows:
iso(1). org(3). dod(6). internet(1). mgmt(2). mib-2(1)
Example of the OID for getting the description of a device:
system.sysDescr.0 = .1.3.6.1.2.1.1.1.0
Old legacy management systems required "loading" a MIB file for every device that needs to be monitored. This method was cumbersome, and required the user to correlate the different parts of the MIB tree to get a useful metric like "line utilization". Traverse uses an external XML library of SNMP variables, which eliminates the need to load MIB files since all the relevant MIB variables and the post-processing rules for each variable are stored in industry standard XML format. See Advanced SNMP Tests and Using the MIB Browser.
Security Concerns
You can set up the community string on the router or switch to allow read-only SNMP queries or also allow "setting" variables. It is recommended that you only allow "reading" SNMP variables for security purposes and disable setting of the SNMP parameters.
RMON2
RMON2 support in network routers and switches allows gathering metrics on the type of network traffic using SNMP. You need to configure the RMON2 enabled device (interface) to log the type of traffic (instructions are implementation/hardware/vendor specific). By default, most RMON2 implementations monitor common ports, like TCP/http, TCP/telnet, UDP/dns, etc. Some vendor devices will not respond to RMON2 queries for a protocol until at least one packet of that particular type has crossed that interface (i.e. the stats table for that protocol will be empty and the host returns an invalid response to an SNMP query). So even if the RMON2 interface knows about SSH, no SSH specific stats will show up on the stats table, and therefore in the Traverse auto-discovery.
The RMON2 protocol allows defining additional protocols that can be monitored in addition to the default ones. For details on how to determine the protocol identifier, see RFC-2074 at http://www.ietf.org/rfc/rfc2074.txt.
IP-SLA (SAA)
IP Service Level Agreements are a built in feature of Cisco IOS which measures response times of various business critical applications at the end-to-end and at the IP layer. Cisco's IP-SLA feature uses active monitoring to generate traffic for VoIP, FTP, SMTP, HTTP and other such protocols and then measuring the performance metrics for accurate measurement.
Traverse can actively retrieve these IP-SLA metrics and trigger alerts when these measurements indicate degradation of the SLA performance.