Using SNMP


The snmp-server command causes the firewall to send SNMP traps so that the firewall can be monitored remotely. Use snmp-server host command to specify which systems receive the SNMP traps.


Introduction

The firewall SNMP MIB-II groups available are System and Interfaces. The Cisco Firewall MIB and Cisco Memory Pool MIB are also available.

All SNMP values are read only (RO).

Using SNMP, you can monitor system events on the firewall. SNMP events can be read, but information on the firewall cannot be changed with SNMP.

The firewall SNMP traps available to an SNMP management station are as follows:

  • Generic traps:

    • Link up and link down (cable connected to the interface or not; cable connected to an interface working or not working)

    • Cold start

    • Authentication failure (mismatched community string)

  • Security-related events sent via the Cisco Syslog MIB:

    • Global access denied

    • Failover syslog messages

    • syslog messages

Use CiscoWorks for Windows or any other SNMP V1, MIB-II compliant browser to receive SNMP traps and browse an MIB. SNMP traps occur at UDP port 162.


MIB Support

You can browse the System and Interface groups of MIB-II. Browsing an MIB is different from sending traps. Browsing means doing an snmpget or snmpwalk of the MIB tree from the management station to determine values.

MIB Support

The Cisco Firewall MIB and Cisco Memory Pool MIB are available.

The firewall does not support the following in the Cisco Firewall MIB:

  • cfwSecurityNotification NOTIFICATION-TYPE

  • cfwContentInspectNotification NOTIFICATION-TYPE

  • cfwConnNotification NOTIFICATION-TYPE

  • cfwAccessNotification NOTIFICATION-TYPE

  • cfwAuthNotification NOTIFICATION-TYPE

  • cfwGenericNotification NOTIFICATION-TYPE


SNMP Usage Notes

  • The MIB-II ifEntry.ifAdminStatus object returns 1 if the interface is accessible and 2 if you administratively shut down the interface using the shutdown option of the interface command.

  • The SNMP "ifOutUcastPkts" object now correctly returns the outbound packet count.

  • Syslog messages generated by the SNMP module now specify the interface name instead of an interface number.


SNMP Traps

Traps are different than browsing; they are unsolicited "comments" from the managed device to the management station for certain events, such as link up, link down, and syslog event generated.

An SNMP object ID (OID) for firewall displays in SNMP event traps sent from the firewall. firewall provides system OID in SNMP event traps & SNMP mib-2.system.sysObjectID variable based on the hardware platform:

Table 7-1 lists the system OID in firewall platforms:


Table 7-1: System OID in firewall Platforms
PIX Platform System OID
PIX 506 .1.3.6.1.4.1.9.1.389
PIX 515 .1.3.6.1.4.1.9.1.390
PIX 520 .1.3.6.1.4.1.9.1.391
PIX 525 .1.3.6.1.4.1.9.1.392
PIX 535 .1.3.6.1.4.1.9.1.393
others .1.3.6.1.4.1.9.1.227 (original firewall OID)

Two mechanisms work with SNMP, firewall responds to an SNMP request from a management station and the firewall sends a trap, which is an event notification. firewall supports two types of traps, generic and syslog traps.

Receiving Requests and Sending Syslog Traps

Follow these steps to receive requests and send traps from the firewall to an SNMP management station:

  1. Identify the IP address of the SNMP management station with the snmp-server host command.

  2. Set the snmp-server options for location, contact, and the community password as required.

    If you only want to send the cold start, link up, and link down generic traps, no further configuration is required.

    If you only want to receive SNMP requests, no further configuration is required.

  3. Add an snmp-server enable traps command statement.

  4. Set the logging level with the logging history command:
    logging history debugging

    We recommend that you use the debugging level during initial set up and during testing. Thereafter, set the level from debugging to a lower value for production use.

    (The logging history command sets the severity level for SNMP syslog messages.)

  5. Start sending syslog traps to the management station with the logging on command.

  6. To disable sending syslog traps, use the no logging on command or the no snmp-server enable traps command.

The commands in Example 7-2 specify that firewall can receive the SNMP requests from host 192.168.3.2 on the inside interface but does not send SNMP syslog traps to any host.

Example 7-2: Enabling SNMP

snmp-server host 192.168.3.2
snmp-server location building 42
snmp-server contact polly hedra
snmp-server community ohwhatakeyisthee

The location and contact commands identify where the host is and who administers it. The community command specifies the password in use at the firewall SNMP agent and the SNMP management station for verifying network access between the two systems.


Compiling Cisco Syslog MIB Files

To receive security and firewall SNMP traps from the firewall, compile the Cisco SMI MIB and the Cisco syslog MIB into the SNMP management application. If you do not compile the Cisco syslog MIB into the application, you only receive traps for link up or down, firewall cold start and authentication failure.

You can select Cisco MIB files for firewall and other Cisco products from the following website:

From this page, select firewall from the Cisco Secure & VPN selection list.

Follow these steps to compile Cisco syslog MIB files into the browser using CiscoWorks for Windows (SNMPc):

  1. Get the Cisco syslog MIB files.

  2. Start SNMPc.

  3. Click Config>Compile MIB.

  4. Scroll to the bottom of the list, and click the last entry.

  5. Click Add.

  6. Find the Cisco syslog MIB files.

    With certain applications, only files with a .mib extension may show in the file selection window of the SNMPc. The Cisco syslog MIB files with the .my extension will not be shown. In this case, you should manually change the .my extension to a .mib extension.

  7. Click CISCO-FIREWALL-MIB.my (CISCO-FIREWALL-MIB.mib) and click OK.

  8. Scroll to the bottom of the list, and click the last entry.

  9. Click Add.

  10. Find the file CISCO-MEMORY-POOL-MIB.my (CISCO-MEMORY-POOL-MIB.mib) and click OK.

  11. Scroll to the bottom of the list, and click the last entry.

  12. Click Add.

  13. Find the file CISCO-SMI.my (CISCO-SMI.mib) and click OK.

  14. Scroll to the bottom of the list, and click the last entry.

  15. Click Add.

  16. Find the file CISCO-SYSLOG-MIB.my (CISCO-SYSLOG-MIB.mib) and click OK.

  17. Click Load All.

  18. If there are no errors, restart SNMPc.


Using the Firewall and Memory Pool MIBs

The Cisco Firewall and Memory Pool MIBs let you poll failover and system status.

In the tables that follow in each section, the meaning of each returned value is shown in parentheses.

ipAddrTable Notes

Use of the SNMP ip.ipAddrTable entry requires that all interfaces have unique addresses. If interfaces have not been assigned IP addresses, by default, their IP addresses are all set to 127.0.0.1. Having duplicate IP addresses causes the SNMP management station to loop indefinitely. The workaround is to assign each interface a different address. For example, you can set one address to 127.0.0.1, another to 127.0.0.2, and so on.

SNMP uses a sequence of GetNext operations to traverse the MIB tree. Each GetNext request is based on the result of the previous request. Therefore, if two consecutive interfaces have the same IP 127.0.0.1 (table index), the GetNext function returns 127.0.0.1, which is correct; however, when SNMP generates the next GetNext request using the same result (127.0.0.1), the request is identical to the previous one, which causes the management station to loop infinitely.

For example:

GetNext(ip.ipAddrTable.ipAddrEntry.ipAdEntAddr.127.0.0.1)

In SNMP protocol, the MIB table index should be unique for the agent to identify a row from the MIB table. The table index for ip.ipAddrTable is the firewall interface IP address, so the IP address should be unique; otherwise, the SNMP agent will get confused and may return information of another interface (row), which has the same IP (index).

Viewing Failover Status

The Cisco Firewall MIB's cfsHardwareStatusTable allows you to determine whether failover is enabled and which unit is active. The Cisco Firewall MIB indicates failover status by two rows in the cfwHardwareStatusTable object. From the firewall command line, you can view failover status with the show failover command. You can access the object table from the following path:

.iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoFirewallMIB.
ciscoFirewallMIBObjects.cfwSystem.cfwStatus.cfwHardwareStatusTable

Table 7-2: Failover Status Objects

Table 7-2 lists which objects provide failover information.
Object Object Type Row 1: Returned if Failover is Disabled Row 1: Returned if Failover is Enabled Row 2: Returned if Failover is Enabled
cfwHardwareType
(table index)
Hardware 6 (If primary unit) 6 (If primary unit) 7 (If secondary unit)
cfwHardwareInformation SnmpAdminString blank blank blank
cfwHardwareStatusValue HardwareStatus 0 (Not used) active or 9 (If active unit) or standby or 10 (If standby unit) active or 9 (If active unit) or standby or 10 (If standby unit)
cfwHardwareStatusDetail SnmpAdminString Failover Off blank blank

In the HP OpenView Browse MIB application's "MIB values" window, if failover is disabled, a sample MIB query yields the following information:

cfwHardwareInformation.6 :
cfwHardwareInformation.7 :
cfwHardwareStatusValue.6 :0
cfwHardwareStatusValue.7 :0
cfwHardwareStatusDetail.6 :Failover Off
cfwHardwareStatusDetail.7 :Failover Off

From this listing, the table index, cfwHardwareType, appears as either .6 or .7 appended to the end of each of the subsequent objects. The cfwHardwareInformation field is blank, the cfwHardwareStatusValue is 0, and the cfwHardwareStatusDetail contains Failover Off, which indicates the failover status.

When failover is enabled, a sample MIB query yields the following information:

cfwHardwareInformation.6 :
cfwHardwareInformation.7 :
cfwHardwareStatusValue.6 : active
cfwHardwareStatusValue.7 : standby
cfwHardwareStatusDetail.6 :
cfwHardwareStatusDetail.7 :

In this listing, only the cfwHardwareStatusValue contains values, either active or standby to indicate the status of each unit.

Verifying Memory Usage

You can determine how much free memory is available with the Cisco Memory Pool MIB. From the firewall command line, memory usage is viewed with the show_memory command. The following is sample output from the show memory command.

show memory
16777216 bytes total, 5595136 bytes free

You can access the MIB objects from the following path:

.iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.
ciscoMemoryPoolMIB.ciscoMemoryPoolObjects.ciscoMemoryPoolTable

Table 7-3 lists which objects provide memory usage information.

Table 7-3: Memory Usage Objects

Object Object Type Returned Value
ciscoMemoryPoolType
(table index)
CiscoMemoryPoolTypes 1 (Processor memory)
ciscoMemoryPoolName DisplayString PIX system memory
ciscoMemoryPoolAlternate Integer32 0 (No alternate memory pool)
ciscoMemoryPoolValid TruthValue true (Means that the values of the remaining objects are valid)
ciscoMemoryPoolUsed Gauge32 integer (Number of bytes currently in use—the total bytes minus the free bytes)
ciscoMemoryPoolFree Gauge32 integer (Number of bytes currently free)
ciscoMemoryPoolLargestFree Gauge32 0 (Information not available)

In the HP OpenView Browse MIB application's "MIB values" window a sample MIB query yields the following information:

ciscoMemoryPoolName.1 :PIX system memory
ciscoMemoryPoolAlternate.1 :0
ciscoMemoryPoolValid.1 :true
ciscoMemoryPoolUsed.1 :12312576
ciscoMemoryPoolFree.1 :54796288
ciscoMemoryPoolLargestFree.1 :0

From this listing, the table index, ciscoMemoryPoolName, appears as the .1 value at the end of each subsequent object value. The ciscoMemoryPoolUsed object lists the number of bytes currently in use, 12312576, and the ciscoMemoryPoolFree object lists the number of bytes currently free 54796288. The other objects always list the values described in Table 7-3.

Viewing The Connection Count

You can view the number of connections in use from the cfwConnectionStatTable in the Cisco Firewall MIB. From the firewall command line, you can view the connection count with the show conn command. The following is sample output from the show conn command to demonstrate where the information in cfwConnectionStatTable originates.

show conn
15 in use, 88 most used

The cfwConnectionStatTable object table can be accessed from the following path:

.iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoFirewallMIB.
ciscoFirewallMIBObjects.cfwSystem.cfwStatistics.cfwConnectionStatTable

Table 7-4 lists which objects provide connection count information.

Table 7-4: Connection Count Objects

Object Object Type Row 1: Returned Value Row 2: Returned Value
cfwConnectionStatService
(Table index)
Services 40 IP(protocol) 40 IP(protocol)
cfwConnectionStatType
(Table index)
ConnectionStat 6 (Current connections in use) 7 (High)
cfwConnectionStatDescription SnmpAdminString number of connections currently in use by the entire firewall highest number of connections in use at any one time since system startup
cfwConnectionStatCount Counter32 0 (Not used) 0 (Not used)
cfwConnectionStatValue Gauge32 integer (In use number) integer (Most used number)

In the HP OpenView Browse MIB application's "MIB values" window a sample MIB query yields the following information:

cfwConnectionStatDescription.40.6 :number of connections currently in use by the entire firewall
cfwConnectionStatDescription.40.7 :highest number of connections in use at any one time since system startup
cfwConnectionStatCount.40.6 :0
cfwConnectionStatCount.40.7 :0
cfwConnectionStatValue.40.6 :15
cfwConnectionStatValue.40.7 :88

From this listing, the table index, cfwConnectionStatService, appears as the .40 appended to each subsequent object and the table index, cfwConnectionStatType, appears as either .6 to indicate the number of connections in use or .7 to indicate the most used number of connections. The cfwConnectionStatValue object then lists the connection count. The cfwConnectionStatCount object always returns 0 (zero).

Viewing System Buffer Usage

You can view the system buffer usage from the Cisco Firewall MIB in multiple rows of the cfwBufferStatsTable. The system buffer usage provides an early warning of the firewall reaching the limit of its capacity. On the command line, you can view this information with the show blocks command. The following is sample output from the show blocks command to demonstrate how cfwBufferStatsTable is populated.

show blocks

SIZE MAX LOW CNT

4 1600 1600 1600

80 100 97 97

256 80 79 79

1550 780 402 404

65536 8 8 8

You can view cfwBufferStatsTable at the following path:

.iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoFirewallMIB.
ciscoFirewallMIBObjects.cfwSystem.cfwStatistics.cfwBufferStatsTable

Table 7-5 lists the objects required to view the system block usage.

Table 7-5: System Block Usage Objects

Object Object Type First Row: Returned Value Next Row: Returned Value Next Row: Returned Value
cfwBufferStatSize
(Table index)
Unsigned32 integer (SIZE value; for example, 4 for a 4-byte block) integer (SIZE value; for example, 4 for a 4-byte block) integer (SIZE value; for example, 4 for a 4-byte block)
cfwBufferStatType
(Table index)
ResourceStatistics 3 (MAX) 5 (LOW) 8 (CNT)
cfwBufferStatInformation SnmpAdminString maximum number of allocated integer byte blocks (integer is the number of bytes in a block) fewest integer byte blocks available since system startup (integer is the number of bytes in a block) current number of available integer byte blocks (integer is the number of bytes in a block)
cfwBufferStatValue Gauge32 integer (MAX number) integer (LOW number) integer (CNT number)

The three rows repeat for every block size listed in the output of the show blocks command.

In the HP OpenView Browse MIB application's "MIB values" window a sample MIB query yields the following information:

cfwBufferStatInformation.4.3 :maximum number of allocated 4 byte blocks
cfwBufferStatInformation.4.5 :fewest 4 byte blocks available since system startup
cfwBufferStatInformation.4.8 :current number of available 4 byte blocks
cfwBufferStatInformation.80.3 :maximum number of allocated 80 byte blocks
cfwBufferStatInformation.80.5 fewest 80 byte blocks available since system startup
cfwBufferStatInformation.80.8 :current number of available 80 byte blocks
cfwBufferStatInformation.256.3 :maximum number of allocated 256 byte blocks
cfwBufferStatInformation.256.5 :fewest 256 byte blocks available since system startup
cfwBufferStatInformation.256.8 :current number of available 256 byte blocks
cfwBufferStatInformation.1550.3 :maximum number of allocated 1550 byte blocks
cfwBufferStatInformation.1550.5 :fewest 1550 byte blocks available since system startup
cfwBufferStatInformation.1550.8 :current number of available 1550 byte blocks
cfwBufferStatValue.4.3: 1600
cfwBufferStatValue.4.5: 1600
cfwBufferStatValue.4.8: 1600
cfwBufferStatValue.80.3: 400
cfwBufferStatValue.80.5: 396
cfwBufferStatValue.80.8: 400
cfwBufferStatValue.256.3: 1000
cfwBufferStatValue.256.5: 997
cfwBufferStatValue.256.8: 999
cfwBufferStatValue.1550.3: 1444
cfwBufferStatValue.1550.5: 928
cfwBufferStatValue.1550.8: 932

From this listing, the first table index, cfwBufferStatSize, appears as first number appended to the end of each object, such as .4 or .256. The other table index, cfwBufferStatType, appears as .3, .5, or .8 after the first index. For each block size, the cfwBufferStatInformation object identifies the type of value and the cfwBufferStatValue object identifies the number of bytes for each value.