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 PlatformsPIX 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:
- Identify the IP address of the SNMP management station with the snmp-server host command.
- 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.
- Add an snmp-server enable traps command statement.
- Set the logging level with the logging history command:
logging history debuggingWe 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.)
- Start sending syslog traps to the management station with the logging on command.
- 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 ohwhatakeyistheeThe 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):
- Get the Cisco syslog MIB files.
- Start SNMPc.
- Click Config>Compile MIB.
- Scroll to the bottom of the list, and click the last entry.
- Click Add.
- 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.
- Click CISCO-FIREWALL-MIB.my (CISCO-FIREWALL-MIB.mib) and click OK.
- Scroll to the bottom of the list, and click the last entry.
- Click Add.
- Find the file CISCO-MEMORY-POOL-MIB.my (CISCO-MEMORY-POOL-MIB.mib) and click OK.
- Scroll to the bottom of the list, and click the last entry.
- Click Add.
- Find the file CISCO-SMI.my (CISCO-SMI.mib) and click OK.
- Scroll to the bottom of the list, and click the last entry.
- Click Add.
- Find the file CISCO-SYSLOG-MIB.my (CISCO-SYSLOG-MIB.mib) and click OK.
- Click Load All.
- 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.cfwHardwareStatusTableTable 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 OffFrom 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 freeYou can access the MIB objects from the following path:
.iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.
ciscoMemoryPoolMIB.ciscoMemoryPoolObjects.ciscoMemoryPoolTableTable 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 usethe 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 :0From 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 usedThe cfwConnectionStatTable object table can be accessed from the following path:
.iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoFirewallMIB.
ciscoFirewallMIBObjects.cfwSystem.cfwStatistics.cfwConnectionStatTableTable 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 :88From 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.
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.cfwBufferStatsTableTable 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: 932From 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.