-
Cisco IOS Configuration Fundamentals and Network Management Command Reference, Release 12.3
-
Introduction
-
CFR Commands: absolute -- clock timezone
-
CFR Commands: clock update-calendar -- escape-character
-
CFR Commands: exception core-file -- ip ftp passive
-
CFR Commands: ip ftp password -- lsr-path
-
CFR Commands: memory sanity -- periodic
-
CFR Commands: ping -- service sequence numbers
-
CFR Commands: service slave-log -- show
tee -
CFR Commands: show context -- show ip http server
-
CFR Commands: show kron schedule -- show rtr enhanced-history
-
12.3 CF CR Commands: show rtr distributions-statistics -- snmp-server enable informs
-
CFR Commands: snmp-server enable traps -- statistics-distribution-interval
-
CFR Commands: stopbits -- ttl ip
-
CFR Commands: type dhcp - xsm vdm
-
CFR Appendix: ASCII Character Set and Hex Values
-
Table Of Contents
snmp-server enable traps aaa_server
snmp-server enable traps atm pvc extension mibversion
snmp-server enable traps atm pvc extension
snmp-server enable traps atm pvc
snmp-server enable traps atm subif
snmp-server enable traps calltracker
snmp-server enable traps director
snmp-server enable traps envmon
snmp-server enable traps frame-relay
snmp-server enable traps frame-relay subif
snmp-server enable traps mpls ldp
snmp-server enable traps mpls traffic-eng
snmp-server enable traps mpls vpn
snmp-server enable traps pppoe
snmp-server enable traps repeater
snmp-server enable traps syslog
snmp-server enable traps voice poor-qov
snmp-server manager session-timeout
snmp-server trap-authentication
statistics-distribution-interval
snmp-server enable traps
To enable all Simple Network Management Protocol (SNMP) notifications (traps or informs) available on your system, use the snmp-server enable traps command in global configuration mode. To disable all available SNMP notifications, use the no form of this command.
snmp-server enable traps [notification-type]
no snmp-server enable traps [notification-type]
Syntax Description
Defaults
This command is disabled by default. Most notification types are disabled. However, some notification types cannot be controlled with this command.
If you enter this command with no notification-type keyword extenstions, the default is to enable (or diable, if the no form is used) all notification types controlled by this command.
Command Modes
Global configuration
Command History
10.3
This command was introduced.
12.0(2)T
The rsvp keyword was added.
12.0(3)T
The hsrp keyword was added.
Usage Guidelines
For additional notification types, see the Related Commands table for this command.
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests for the specified notification types. To specify whether the notifications should be sent as traps or informs, use the snmp-server host [traps | informs] command.
If you do not enter an snmp-server enable traps command, no notifications controlled by this command are sent. In order to configure the router to send these SNMP notifications, you must enter at least one snmp-server enable traps command. If you enter the command with no keywords, all notification types are enabled. If you enter the command with a keyword, only the notification type related to that keyword is enabled. In order to enable multiple types of notifications, you must issue a separate snmp-server enable traps command for each notification type and notification option.
The snmp-server enable traps command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. In order to send notifications, you must configure at least one snmp-server host command.
Examples
The following example enables the router to send all traps to the host specified by the name myhost.cisco.com, using the community string defined as public:
Router(config)# snmp-server enable trapsRouter(config)# snmp-server host myhost.cisco.com publicThe following example enables the router to send Frame Relay and environmental monitor traps to the host myhost.cisco.com using the community string public:
Router(config)# snmp-server enable traps frame-relayRouter(config)# snmp-server enable traps envmon temperatureRouter(config)# snmp-server host myhost.cisco.com publicThe following example will not send traps to any host. The BGP traps are enabled for all hosts, but the only traps enabled to be sent to a host are ISDN traps (which are not enabled in this example).
Router(config)# snmp-server enable traps bgpRouter(config)# snmp-server host bob public isdnThe following example enables the router to send all inform requests to the host at the address myhost.cisco.com, using the community string defined as public:
Router(config)# snmp-server enable trapsRouter(config)# snmp-server host myhost.cisco.com informs version 2c publicThe following example sends HSRP MIB traps to the host myhost.cisco.com using the community string public.
Router(config)# snmp-server enable traps hsrpRouter(config)# snmp-server host myhost.cisco.com traps version 2c public hsrpRelated Commands
snmp-server enable traps aaa_server
To enable authentication, authorization, and accounting (AAA) server state-change Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps aaa_server command in global configuration mode. To disable AAA server state-change SNMP notifications, use the no form of this command.
snmp-server enable traps aaa_server
no snmp-server enable traps aaa_server
Syntax Description
This command has no arguments or keywords.
Defaults
SNMP notifications are disabled by default.
Command Modes
Global configuration
Command History
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests.
This command controls (enables or disables) AAA Server state change (casServerStateChange) notifications. ServerStateChange notifications, when enabled, will be sent when the server moves from an "up" to "dead" state or when a server moves from a "dead" to "up" state.
The Cisco AAA Server State is defined by the casState object in the Cisco AAA Server MIB. The possible values are as follows:
•
up(1)—Server is responding to requests.
•
A server is marked "dead" if it does not respond after maximum retransmissions. A server is marked "up" again either after a waiting period or if some response is received from it. The initial value of casState is "up(1)" at system startup. This will only transition to "dead(2)" if an attempt to communicate fails.
For a complete description of this notification and additional MIB functions, see the CISCO-AAA-SERVER-MIB.my file, available on Cisco.com at http://www.cisco.com/public/mibs/v2/.
The snmp-server enable traps aaa_sever command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. To send SNMP notifications, you must configure at least one snmp-server host command.
Examples
The following example enables the router to send AAA server up/down informs to the host at the address myhost.cisco.com using the community string defined as public:
Router(config)# snmp-server enable traps aaa_serverRouter(config)# snmp-server host myhost.cisco.com informs version 2c publicRelated Commands
snmp-server enable traps atm pvc extension mibversion
To specify the MIB that supports extended ATM permanent virtual circuit (PVC) Simple Network Management Protocol (SNMP) notifications or the MIB that supports SNMP notifications for ATM Operation, Administration, and Maintenance (OAM) F5 continuity check (CC) management, ATM OAM F5 AIS/RDI management, and F5 loopback failure management, use the snmp-server enable traps atm pvc extension mibversion command in global configuration mode. To remove the MIB specification, use the no form of this command.
snmp-server enable traps atm pvc extension mibversion {1 | 2}
no snmp-server enable traps atm pvc extension mibversion {1 | 2}
Syntax Description
Defaults
MIB version: 1
Command Modes
Global configuration
Command History
Usage Guidelines
MIB version 1 specifies the MIB that supports legacy extended ATM PVC traps and is defined in the file CISCO-IETF-ATM2-PVCTRAP-MIB-EXTN.my. MIB version 1 is implemented by default. Use the snmp-server enable traps atm pvc extension mibversion 1 command or the no snmp-server enable traps atm pvc extension mibversion 2 command to reenable this MIB if it was previously disabled with the snmp-server enable traps atm pvc extension mibversion 2 command.
Use the snmp-server enable traps atm pvc extension mibversion 2 command to specify the MIB that supports ATM OAM F5 CC and ATM OAM AID/RDI failure notifications. This MIB is defined in the file CISCO-ATM-PVCTRAP-EXTN-MIB.my.
To enable the SNMP notifications that support ATM OAM F5 continuity checking, use the snmp-server enable traps atm pvc extension command in global configuration mode. These SNMP notifications are defined in the file CISCO-ATM-PVCTRAP-EXTN-MIB.my, available from the Cisco FTP site at ftp://www.cisco.com/public/mibs/v2/.
OAM management and support for OAM F5 continuity checking must be enabled on the PVC by using the oam-pvc manage cc command before you can use the ATM OAM continuity check SNMP notifications.
Examples
In the following example, the MIB that supports the SNMP notifications for ATM OAM continuity checking is implemented, and the ATM OAM continuity checking notifications are enabled. Support for end-to-end OAM F5 continuity checking is enabled on PVC 0/1:
Router(config)# snmp-server enable traps atm pvc extension mibversion 2Router(config)# snmp-server enable traps atm pvc extension oam failure aisrdiRouter(config)# snmp-server enable traps atm pvc extension oam failure endccRouter(config)# snmp-server enable traps atm pvc extension oam failure segmentccRouter(config)# snmp-server enable traps atm pvc extension oam failure loopbackRouter(config)# snmp-server enable traps atm pvc extension upRouter(config)# interface atm 0Router(config-if)# pvc 0/40Router(config-if-atm-vc)# oam-pvc manage cc endRelated Commands
snmp-server enable traps atm pvc extension
To enable the sending of extended ATM permanent virtual circuit (PVC) SNMP notifications and SNMP notifications for ATM Operation, Administration, and Maintenance (OAM) F5 continuity check (CC), ATM OAM F5 alarm indication signals/remote defect indications (AIS/RDI), and loopback failures, use the snmp-server enable traps atm pvc extension command in global configuration mode. To disable these SNMP notifications, use the no form of this command.
snmp-server enable traps atm pvc extension {up | down | oam failure [aisrdi | endCC | loopback | segmentCC]}
no snmp-server enable traps atm pvc extension{up | down | oam failure [aisrdi | endCC | loopback | segmentCC]}
Syntax Description
Defaults
SNMP notifications are disabled.
The interval between successive traps is 30 seconds.Command Modes
Global configuration
Command History
Usage Guidelines
For PVCs that are not part of a range, extended ATM PVC traps include virtual path identifier/virtual channel indentifier (VPI/ VCI) information, the number of state transitions a PVC goes through in an interval, and the timestamp for the start and end of the transitions. For PVCs that are part of a range, extended ATM PVC traps include the first and last VPI/VCI of the range and the timestamp for the first failure and the last failure within the same range.
Extended ATM PVC and ATM OAM F5 CC traps cannot be used at the same time as the legacy ATM PVC trap. The legacy ATM PVC trap must be disabled by using the no snmp-server enable traps atm pvc command before extended ATM PVC traps can be configured.
The extended ATM PVC failure trap (which is is enabled by the snmp-server enable traps atm pvc extension down command) is the same trap as the legacy ATM PVC failure trap (which is enabled by the snmp-server enable traps atm pvc command), but with the the following differences:
•
•
•
Note
OAM management must be enabled on the PVC before you can use ATM PVC traps. To generate F5 loopback failure traps, enable OAM management using the oam-pvc manage command. To generate segment F5 CC failure traps, enable segment OAM CC management by using the oam-pvc manage cc segment command. To generate end-to-end F5 CC failure traps, enable end-to-end OAM CC management by using the oam-pvc manage cc end command. To generate OAM F5 AIS/RDI failure traps, enable any of the three types of OAM management listed above.
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests for the specified notification types.
The extended ATM PVC notifications for MIB version 1 are defined in the CISCO-IETF-ATM2-PVCTRAP-MIB.my file.The extended ATM PVC notifications for MIB version 2 are defined in the CISCO-ATM-PVCTRAP-EXTN-MIB.my file. Both of these MIB files are available from the Cisco FTP site at ftp://www.cisco.com/public/mibs/v2/.
ATM PVC traps are generated at the end of the notification interval. It is possible to generate all three types of ATM PVC traps (the ATM PVC failure trap, ATM PVC up trap, and ATM PVC OAM failure trap) at the end of the same notification interval; however, only one type of trap will be generated for each PVC.
The snmp-server enable traps atm pvc extension command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. In order to send notifications, you must configure at least one snmp-server host command.
When the ATM OAM F5 loopback, AIS/RDI, or CC failure trap is enabled, the PVC remains in the UP state when an OAM loopback, AIS/RDI, or CC failure is detected, so that the flow of data will still be possible. If one of these traps is not enabled, the PVC will be placed in the DOWN state when an OAM loopback, AIS/RDI, or CC failure is detected.
Examples
Extended ATM PVC Notifications Example
The following example shows all three of the extended ATM PVC traps enabled on a router. If PVC 0/1 leaves the UP state, leaves the DOWN state, or has an OAM loopback failure, host 172.16.61.90 will receive the SNMP notifications:
! Configure SNMP support and an IP routing protocol on your router:Router(config)# snmp-server community public roRouter(config)# snmp-server host 172.16.61.90 publicRouter(config)# ip routingRouter(config)# router igrp 109Router(config-router)# network 172.16.0.0!! Enable extended ATM PVC trap support and OAM management:Router(config)# snmp-server enable traps atm pvc extension downRouter(config)# snmp-server enable traps atm pvc extension upRouter(config)# snmp-server enable traps atm pvc extension oam failure loopbackRouter(config)# interface atm 1/0.1Router(config-if)# pvc 0/1Router(config-if-atm-vc)# oam-pvc manageExtended ATM PVC Failure Trap Output: Example
The following example shows output for extended ATM PVC failure trap for PVCs 1/100, 1/102, and 1/103. Note that only one trap is generated for all the PVCs associated with the same interface or subinterface (in contrast to the legacy ATM PVC failure trap, which generates a separate trap for each PVC). The VPI/VCI information and timing information are located in the objects associated with the trap.
00:23:56:SNMP:Queuing packet to 1.1.1.100:23:56:SNMP:V2 Trap, reqid 2, errstat 0, erridx 0sysUpTime.0 = 143636snmpTrapOID.0 = atmIntfPvcFailuresTrapifEntry.1.19 = 19atmIntfPvcFailures.2 = 7atmIntfCurrentlyFailingPVcls.2 = 3atmPVclLowerRangeValue.19.1.2 = 102atmPVclHigherRangeValue.19.1.2 = 103atmPVclRangeStatusChangeStart.19.1.2 = 140643atmPVclRangeStatusChangeEnd.19.1.2 = 140698atmPVclStatusTransition.19.1.100 = 1atmPVclStatusChangeStart.19.1.100 = 140636atmPVclStatusChangeEnd.19.1.100 = 14063600:23:56:SNMP:Packet sent via UDP to 1.1.1.1Extended ATM PVC Up Trap Output: Example
The following example shows output for the extended ATM PVC up trap for PVCs 1/100, 1/102, and 1/103:
00:31:29:SNMP:Queuing packet to 1.1.1.100:31:29:SNMP:V2 Trap, reqid 2, errstat 0, erridx 0sysUpTime.0 = 188990snmpTrapOID.0 = atmIntfPvcUpTrapifEntry.1.19 = 19atmIntfCurrentlyDownToUpPVcls.2 = 3atmPVclLowerRangeValue.19.1.2 = 102atmPVclHigherRangeValue.19.1.2 = 103atmPVclRangeStatusChangeStart.19.1.2 = 186005atmPVclRangeStatusChangeEnd.19.1.2 = 186053atmPVclStatusTransition.19.1.100 = 1atmPVclStatusChangeStart.19.1.100 = 185990atmPVclStatusChangeEnd.19.1.100 = 18599000:31:30:SNMP:Packet sent via UDP to 1.1.1.1ATM OAM F5 CC Notifications Example
In the following example, the ATM OAM CC notifications and an extended ATM PVC notification are enabled. If connectivity failures are detected on PVC 0/1, host 172.16.61.90 will receive the SNMP notifications:
! Configure SNMP support and an IP routing protocol on your router:Router(config)# snmp-server community public roRouter(config)# snmp-server host 172.16.61.90 publicRouter(config)# ip routingRouter(config)# router igrp 109Router(config-router)# network 172.16.0.0!! Enable extended ATM PVC trap support and OAM management:Router(config)# snmp-server enable traps atm pvc extension mibversion 2Router(config)# snmp-server enable traps atm pvc extension oam failure aisrdiRouter(config)# snmp-server enable traps atm pvc extension oam failure endccRouter(config)# snmp-server enable traps atm pvc extension oam failure segmentccRouter(config)# snmp-server enable traps atm pvc extension oam failure loopbackRouter(config)# snmp-server enable traps atm pvc extension upRouter(config)# interface atm 0Router(config-if)# pvc 0/1Router(config-if-atm-vc)# oam-pvc manage cc endRelated Commands
snmp-server enable traps atm pvc
To enable the sending of ATM permanent virtual circuit (PVC) Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps atm pvc command in global configuration mode. To disable ATM PVC-specific SNMP notifications, use the no form of this command.
snmp-server enable traps atm pvc [interval seconds] [fail-interval seconds]
no snmp-server enable traps atm pvc [interval seconds] [fail-interval seconds]
Syntax Description
Defaults
SNMP notifications are disabled by default.
The default interval is 30.
The default fail-interval is 0.
Command Modes
Global configuration
Command History
12.0(1)T
This command was introduced for those platforms that support ATM PVC Management.
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests for the specified notification types. ATM notifications are defined in the CISCO-IETF-ATM2-PVCTRAP-MIB.my file, available from the Cisco FTP site at ftp://www.cisco.com/public/mibs/v2/.
ATM PVC failure notification are sent when a PVC on an ATM interface fails or leaves the UP operational state. Only one trap is generated per hardware interface, within the specified interval defined by the interval keyword (stored as the atmIntfPvcNotificationInterval in the MIB). If other PVCs on the same interface go DOWN during this interval, traps are generated and held until the fail-interval has elapsed. Once the interval has elapsed, the traps are sent if the PVCs are still DOWN.
No notifications are generated when a PVC returns to the UP state after having been in the DOWN state. If you need to detect the recovery of PVCs, you must use the SNMP management application to regularly poll your router.
The snmp-server enable traps atm pvc command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. In order to send notifications, you must configure at least one snmp-server host command.
Examples
The following example shows the enabling of ATM PVC traps on a router, so that if PVC 0/1 goes down, host 172.16.61.90 will receive the notifications:
!For ATM PVC Trap Support to work on your router, you must first have SNMP support and!an IP routing protocol configured on your router:Router(config)# snmp-server community public roRouter(config)# snmp-server host 172.16.61.90 publicRouter(config)# ip routingRouter(config)# router igrp 109Router(config-router)# network 172.16.0.0!!Enable ATM PVC Trap Support and OAM management:Router(config)# snmp-server enable traps atm pvc interval 40 fail-interval 10Router(config)# interface atm 1/0.1Router(config-if)# pvc 0/1Router(config-if-atm-vc)# oam-pvc manageRelated Commands
snmp-server enable traps atm subif
To enable the sending of ATM subinterface Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps atm subif command in global configuration mode. To disable ATM subinterface-specific SNMP notifications, use the no form of this command.
snmp-server enable traps atm subif [interval seconds [count number-of-traps] | [count number-of-traps]
no snmp-server enable traps atm subif [interval seconds [count number-of-traps] | [count number-of-traps]
Syntax Description
Defaults
ATM subinterface SNMP notifications are disabled by default.
Interval: 10 seconds
Count: 10 trapsCommand Modes
Global configuration
Command History
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests for the specified notification types.
ATM subinterface traps are sent to the network management system (NMS) whenever a subinterface enters or leaves the down state.
The count and interval parameters can be configured to limit the number of traps sent and the frequency at which they are sent in order to prevent trap storms. Configuring an interval of 0 seconds causes all ATM subinterface traps to be sent.
You can disable ATM subinterface traps by using the no snmp-server enable traps atm subif command. When traps are disabled, you can use the SNMP management application to poll your router for subinterface status information.
The snmp-server enable traps atm subif command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. In order to send notifications, you must configure at least one snmp-server host command.
The snmp-server trap link ietf command must be configured in order to use the snmp-server enable traps atm subif command. The snmp-server trap link ietf command is used to configure your router to use the RFC 2233 IETF standards-based implementation of linkUp/linkDown traps. The default Cisco object definitions do not generate linkUp/linkDown traps correctly for subinterfaces.
Examples
The following example shows how to enable ATM subinterface traps on a router. If an ATM subinterface on this router changes state, host 172.16.61.90 will receive the notifications:
!For ATM subinterface trap to work on your router, you must first have SNMP support and!an IP routing protocol configured on your router:Router(config)# snmp-server community public roRouter(config)# snmp-server host 172.16.61.90 publicRouter(config)# snmp-server trap link ietfRouter(config)# snmp-server enable traps snmpRouter(config)# ip routingRouter(config)# router igrp 109Router(config-router)# network 172.16.0.0!Enable ATM subinterface trap support:Router(config)# snmp-server enable traps atm subif interval 60 count 5Related Commands
snmp-server enable traps bgp
To enable Border Gateway Protocol (BGP) state-change Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps bgp command in global configuration mode. To disable BGP state-change SNMP notifications, use the no form of this command.
snmp-server enable traps bgp
no snmp-server enable traps bgp
Syntax Description
This command has no arguments or keywords.
Defaults
SNMP notifications are disabled by default.
Command Modes
Global configuration
Command History
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests.
This command controls (enables or disables) BGP server state change notifications, as defined in the BGP4-MIB (enterprise 1.3.6.1.2.1.15.7). The notifications types are:
•
•
The BGP notifications are defined in the BGP-4 MIB as follows:
For a complete description of these notifications and additional MIB functions, see the BGP4-MIB.my file, available through the Cisco FTP site at ftp://www.cisco.com/public/mibs/v2/.
Note
The snmp-server enable traps bgp command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. To send SNMP notifications, you must configure at least one snmp-server host command.
Examples
The following example enables the router to send BGP state change informs to the host at the address myhost.cisco.com using the community string defined as public:
Router(config)# snmp-server enable traps bgpRouter(config)# snmp-server host myhost.cisco.com informs version 2c publicRelated Commands
snmp-server host
Specifies the recipient of an SNMP notification operation.
snmp-server trap-source
Specifies the interface that an SNMP trap should originate from.
snmp-server enable traps calltracker
To enable Call Tracker CallSetup and Call Terminate Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps calltracker command in global configuration mode. To disable Call Tracker SNMP notifications, use the no form of this command.
snmp-server enable traps calltracker
no snmp-server enable traps calltracker
Syntax Description
This command has no arguments or keywords.
Defaults
SNMP notifications are disabled by default.
Command Modes
Global configuration
Command History
12.1(3)T
This command was introduced for the Cisco AS5300 and Cisco AS580 access servers.
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests.
This command controls (enables or disables) Call Tracker CallSetup and CallTerminate notifications. CallSetup notifications are generated at the start of each call, when an entry is created in the active table (cctActiveTable), and CallTerminate notifications are generated at the end of each call, when an entry is created in the history table (cctHistoryTable).
For a complete description of these notifications and additional MIB functions, refer to the CISCO-CALL-TRACKER-MIB.my file, available on Cisco.com at http://www.cisco.com/public/mibs/v2/.
The snmp-server enable traps calltracker command is used in conjunction with the snmp-server host global configuration command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. To send SNMP notifications, you must configure at least one snmp-server host command.
Examples
The following example enables the router to send call-start and call-stop informs to the host at the address myhost.cisco.com using the community string defined as public:
Router(config)# snmp-server enable traps calltrackerRouter(config)# snmp-server host myhost.cisco.com informs version 2c public calltrackerRelated Commands
snmp-server enable traps director
To enable DistributedDirector Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps director command in global configuration mode. To disable DistributedDirector SNMP notifications, use the no form of this command.
snmp-server enable traps director [server-up | server-down]
no snmp-server enable traps director [server-up | server-down]
Syntax Description
Defaults
SNMP notifications are disabled by default.
Command Modes
Global configuration
Command History
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests.
This command controls (enables or disables) DistributedDirector status notifications for systems. If none of the optional keywords is specified, all available environmental notifications are enabled.
Examples
In the following example, both ciscoDistDirEventServerUp and ciscoDistDirEventServerDown notifications are enabled:
Router(config)# snmp-server enable traps directorRouter# show running-configip host myhost 172.2.2.10 172.2.2.20 172.2.2.30...ip director host myhostip dns primary myhost soa myhost myhost@comip director host myhost priority boomerang 1no ip director drp synchronizedsnmp-server enable traps director server-up server-downRelated Commands
snmp-server enable traps dlsw
To enable the sending of Data Link Switch (DLSw) circuit and peer connection Simple Network Management Protocol (SNMP) notifications (traps and informs), use the snmp-server enable traps dlsw command in global configuration mode. To disable DLSw notifications, use the no form of this command.
snmp-server enable traps dlsw [circuit | tconn]
no snmp-server enable traps dlsw [circuit | tconn]
Syntax Description
Defaults
SNMP notifications are disabled by default.
If the optional keywords are not used, all DLSw notification types are enabled (or disabled, if the no form is used).
Command Modes
Global configuration
Command History
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests. Use this command in conjunction with the snmp-server host command.
This command controls (enables or disables) SNMP notifications for Data Link Switch (DLSw) circuit and connection activity. DLSw objects are defined in the Cisco DLSw MIB module (CISCO-DLSW-MIB.my) and the DLSw+ (Cisco Specific Features) MIB module (CISCO-DLSW-EXT-MIB.my), available through Cisco.com at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
Examples
In the following example the device is configured to send DLSw circuit state change informs to the host at the address myhost.cisco.com using the community string defined as public:
Router(config)# snmp-server enable traps dlsw circuitRouter(config)# snmp-server host myhost.cisco.com informs version 2c publicRelated Commands
snmp-server host
Specifies the recipient of an SNMP notification operation.
snmp-server trap-source
Specifies the interface that an SNMP trap should originate from.
snmp-server enable traps envmon
To enable environmental monitor Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps envmon command in global configuration mode. To disable environmental monitor SNMP notifications, use the no form of this command.
snmp-server enable traps envmon [shutdown] [voltage] [temperature] [fan] [supply]
no snmp-server enable traps envmon [shutdown] [voltage] [temperature] [fan] [supply]
Syntax Description
Defaults
SNMP notifications are disabled by default.
Command Modes
Global configuration
Command History
10.3
This command was introduced.
11.3(6)AA
Support for this command was introduced for the Cisco AS5300 access server.
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests.
This command controls (enables or disables) Environmental Monitor (EnvMon) status notifications for supported systems. Cisco enterprise EnvMon notifications are triggered when an environmental threshold is exceeded. If none of the optional keywords are specified, all available environmental notifications are enabled.
For a complete description of these notifications and additional MIB functions, see the CISCO-ENVMON-MIB.my and CISCO-ACCESS-ENVMON-MIB.my files, available on Cisco.com at http://www.cisco.com/public/mibs/v2/.
Status of the Environmental Monitor can be viewed using the show environment command.
The snmp-server enable traps envmon command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. To send SNMP notifications, you must configure at least one snmp-server host command.
Examples
The following example enables a Cisco 12000 GSR to send environmental failure informs to the host at the address myhost.cisco.com using the community string defined as public:
Router(config)# snmp-server enable traps envmonRouter(config)# snmp-server host myhost.cisco.com informs version 2c public envmonRelated Commands
snmp-server enable traps frame-relay
To enable Frame Relay Data Link Connection Identifier (DLCI) and subinterface Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps frame-relay command in global configuration mode. To disable Frame Relay DLCI and subinterface SNMP notifications, use the no form of this command.
snmp-server enable traps frame-relay
no snmp-server enable traps frame-relay
Syntax Description
This command has no arguments or keywords.
Defaults
SNMP notifications are disabled by default.
Command Modes
Global configuration
Command History
10.3
This command was introduced.
12.2(13)T
This command was modified to enable Frame Relay subinterface traps in addition to DLCI traps.
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests.
This command controls (enables or disables) DLCI Frame Relay notifications, as defined in the RFC1315-MIB (enterprise 1.3.6.1.2.1.10.32).
This trap indicates that the indicated virtual circuit (VC) or subinterface has changed state, meaning that the VC or subinterface has either been created or invalidated, or has toggled between the active and inactive states.
To enable only Frame Relay subinterface traps, use the snmp-server enable traps frame-relay subif command.
Note
For a complete description of this notification and additional MIB functions, see the RFC1315-MIB.my file and the CISCO-FRAME-RELAY-MIB.my file, available in the "v1" and "v2" directories, respectively, at the Cisco.com MIB web site at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
The snmp-server enable traps frame-relay command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. To send SNMP notifications, you must configure at least one snmp-server host command.
Examples
In the following example, the router is configured to send Frame Relay DLCI and subinterface state change informs to the host at the address myhost.cisco.com using the community string defined as public:
Router(config)# snmp-server enable traps frame-relayRouter(config)# snmp-server host myhost.cisco.com informs version 2c publicRelated Commands
snmp-server host
Specifies the recipient of an SNMP notification operation.
snmp-server trap-source
Specifies the interface that an SNMP trap should originate from.
snmp-server enable traps frame-relay subif
To enable Frame Relay subinterface Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps frame-relay subif command in global configuration mode. To disable Frame Relay subinterface SNMP notifications, use the no form of this command.
snmp-server enable traps frame-relay subif [interval seconds [count number-of-traps] | [count number-of-traps]
no snmp-server enable traps frame-relay subif [interval seconds [count number-of-traps] | [count number-of-traps]
Syntax Description
Defaults
Frame Relay subinterface SNMP notifications are disabled by default.
Interval: 10 seconds
Count: 10 trapsCommand Modes
Global configuration
Command History
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests.
Frame Relay subinterface traps are sent to the network management system (NMS) whenever a subinterface enters or leaves the down state.
The count and interval parameters can be configured to limit the number of traps sent and the frequency at which they are sent in order to prevent trap storms. Configuring an interval of 0 seconds causes all Frame Relay subinterface traps to be sent.
Note
You can disable Frame Relay subinterface traps by using the no snmp-server enable traps frame-relay subif command. When traps are disabled, you can use the SNMP management application to poll your router for subinterface status information.
The snmp-server enable traps frame-relay subif command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. In order to send notifications, you must configure at least one snmp-server host command.
The snmp-server trap link ietf command must be configured in order to use the snmp-server enable traps frame-relay subif command. The snmp-server trap link ietf command is used to configure your router to use the RFC 2233 IETF standards-based implementation of linkUp/linkDown traps. The default Cisco object definitions do not generate linkUp/linkDown traps correctly for subinterfaces.
Examples
The following example shows how to enable Frame Relay subinterface traps on a router. If a Frame Relay subinterface on this router changes state, host 172.16.61.90 will receive the notifications:
! For Frame Relay subinterface traps to work on your router, you must first have SNMP ! support and an IP routing protocol configured on your router:Router(config)# snmp-server community public roRouter(config)# snmp-server host 172.16.61.90 publicRouter(config)# snmp-server trap link ietfRouter(config)# snmp-server enable traps snmpRouter(config)# ip routingRouter(config)# router igrp 109Router(config-router)# network 172.16.0.0!Enable Frame Relay subinterface trap support:Router(config)# snmp-server enable traps frame-relay subif interval 60 count 5Related Commands
snmp-server enable traps isdn
To enable the sending of Integrated Services Digital Network (ISDN) specific Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps isdn command in global configuration mode. To disable ISDN-specific SNMP notifications, use the no form of this command.
snmp-server enable traps isdn [call-information] [chan-not-avail] [isdnu-interface] [layer2]
no snmp-server enable traps isdn [call-information] [chan-not-avail] [isdnu-interface] [layer2]
Syntax Description
Defaults
SNMP notifications are disabled by default.
If you enter this command with none of the optional keywords, all available notifications are enabled.
Command Modes
Global configuration
Command History
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests for the specified notification types. ISDN notifications are defined in the CISCO-ISDN-MIB.my and CISCO-ISDNU-IF-MIB.my files, available on Cisco.com at http://www.cisco.com/public/mibs/v2/.
Availability of notifications will depend on your platform. To see what notifications are available, use the snmp-server enable traps isdn ? command.
If you do not enter an snmp-server enable traps isdn command, no notifications controlled by this command are sent. In order to configure the router to send these SNMP notifications, you must enter at least one snmp-server enable traps isdn command. If you enter the command with no keywords, all notification types are enabled. If you enter the command with a keyword, only the notification type related to that keyword is enabled.
The snmp-server enable traps snmp command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. To send SNMP notifications, you must configure at least one snmp-server host command.
Examples
The following example shows the checking of what notification types are available on a Cisco AS5300, and the enabling of channel-not-available and layer2 informs:
NAS(config)#snmp-server enable traps isdn ?call-information Enable SNMP isdn call information trapschan-not-avail Enable SNMP isdn channel not avail trapslayer2 Enable SNMP isdn layer2 transition traps<cr>NAS(config)#snmp-server enable traps isdn chan-not-avail layer2NAS(config)#snmp-server host myhost.cisco.com informs version 2c public isdnRelated Commands
snmp-server enable traps mpls ldp
To enable the sending of Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) SNMP notifications, use the snmp-server enable traps mpls ldp command in global configuration mode. To disable the sending of MPLS LDP notifications, use the no form of this command.
snmp-server enable traps mpls ldp [session-up | session-down | pv-limit | threshold]
no snmp-server enable traps mpls ldp [session-up | session-down | pv-limit | threshold]
Syntax Description
Defaults
The sending of SNMP notifications is disabled by default.
If you do not specify any of the optional keywords, all four types of LDP notifications are enabled on the LSR.
Command Modes
Global configuration
Command History
12.0(21)ST
This command was introduced.
12.2(13)T
This command was implemented in Cisco IOS Release 12.2(13)T.
Usage Guidelines
The MPLS LDP pv-limit (mplsLdpPathVectorLimitMismatch) notification object provides a warning message that can be sent to the NMS when two routers engaged in LDP operations have a dissimilar path vector limit. It is recommended that all LDP-enabled routers in the network be configured with the same path vector limit.
The value of the path vector limit can range from 0 through 255; a value of 0 indicates that loop detection is off; any value other than zero up to 255 indicates that loop detection is on and, in addition, specifies the maximum number of hops through which an LDP message can pass before a loop condition in the network is sensed.
The MPLS LDP threshold (mplsLdpFailedInitSessionThresholdExceeded) notification object provides a warning message that can be sent to a network management station (NMS) when a local LSR and an adjacent LDP peer attempt to set up an LDP session between them, but fail to do so after a specified number of attempts. The default number of attempts is 8. This default value is implemented in Cisco IOS and cannot be changed using either the CLI or an SNMP agent.
In general, Cisco routers support the same features across multiple platforms. Therefore, the most likely incompatibility to occur between Cisco LSRs is a mismatch of their respective ATM VPI/VCI label ranges.
For example, if you specify a range of valid labels for an LSR that does not overlap the range of its adjacent LDP peer, the routers will try eight times to create an LDP session between themselves before the mplsLdpFailedInitSessionThresholdExceeded notification is generated.
Operationally, the LSRs whose label ranges do not overlap continue their attempt to create an LDP session between themselves after the eight retry threshold is exceeded. In such cases, the LDP threshold exceeded notification alerts the network administrator to the existence of a condition in the network that may warrant attention.
RFC 3036, LDP Specification, details the incompatibilities that can exist between Cisco routers and/or other vendor LSRs in an MPLS network. Among such incompatibilities, for example, are the following:
•
•
•
•
The snmp-server enable traps mpls ldp command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. To send SNMP notifications, you must configure at least one snmp-server host command.
Examples
In the following example, LDP-specific informs are enabled and will be sent to the host myhost.cisco.com using the community string defined as public:
Router(config)# snmp-server enable traps mpls ldpRouter(config)# snmp-server host myhost.cisco.com informs version 2c public mpls-ldpsnmp-server enable traps mpls traffic-eng
To enable Multiprotocol Label Switching (MPLS) traffic engineering tunnel state-change SNMP notifications, use the snmp-server enable traps mpls traffic-eng command in global configuration mode. To disable MPLS traffic engineering tunnel state-change SNMP notifications, use the no form of this command.
snmp-server enable traps mpls traffic-eng [up | down | reroute]
no snmp-server enable traps mpls traffic-eng [up | down | reroute]
Syntax Description
Defaults
SNMP notifications are disabled by default.
If this command is used without keywords, all available trap types (up, down, reroute) are enabled.
Command Modes
Global configuration
Command History
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests.
This command controls (enables or disables) MPLS traffic engineering tunnel notifications. MPLS Tunnel StateChange notifications, when enabled, will be sent when the connection moves from an "up" to "down" state, when a connection moves from a "down" to "up" state, or when a connection is rerouted.
If you do not specify a specific argument in conjunction with this command, all three types of MPLS traffic engineering tunnel notifications will be sent.
The snmp-server enable traps mpls traffic-eng command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. To send SNMP notifications, you must configure at least one snmp-server host command.
Examples
The following example enables the router to send MPLS notifications to the host at the address myhost.cisco.com using the community string defined as public:
Router(config)# snmp-server enable traps mpls traffic-engRouter(config)# snmp-server host myhost.cisco.com informs version 2c publicRelated Commands
snmp-server host
Specifies the recipient of an SNMP notification operation.
snmp-server trap-source
Specifies the interface that an SNMP trap should originate from.
snmp-server enable traps mpls vpn
To enable the router to send Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) specific Simple Network Management Protocol (SNMP) notifications (traps and informs), use the snmp-server enable traps mpls vpn command in global configuration mode. To disable MPLS VPN specific SNMP notifications, use the no form of this command.
snmp-server enable traps mpls vpn [vrf-up] [vrf-down] [mid-threshold] [max-threshold] [illegal-label]
no snmp-server enable traps mpls vpn [vrf-up] [vrf-down] [mid-threshold] [max-threshold] [illegal-label]
Syntax Description
Defaults
This command is disabled by default.
Command Modes
Global configuration
Command History
Usage Guidelines
If this command is used without any of the optional keywords, all MPLS VPN notification types are enabled.
For the vrf-up (mplsVrfIfUp) or vrf-down (mplsVrfIfDown) notifications to be issued from an ATM or Frame Relay subinterface, you must first configure the snmp-server traps atm subif command or the snmp-server traps frame-relay subif command on the subinterfaces, respectively.
The values for mid-threshold and max-threshold are set using the maximum routes limit {warn-threshold | warning-only} VRF configuration mode command.
The maximum routes command gives you two options:
•
•
If you choose maximum routes limit warning-only form of the command, a warning message is generated when the limit is exceeded, and the limit you specify will not be enforced.
If you choose maximum routes limit warn-threshold form of the command, a warning message will be generated when the warn-threshold is reached, and the limit will be enforced.
If you use the maximum routes limit warning-only command with the snmp-server enable traps mpls vpn command, a mid-threshold SNMP notification will be generated when the is limit value is reached or exceeded.
No max-threshold SNMP notification will be generated.
If you used the maximum routes limit warn-threshold command with the snmp-server enable traps mpls vpn command, a mid-threshold SNMP notification will be generated when the warn-threshold value is reached, and a max-threshold notification will be generated when the limit value is reached.
The notification types described above are defined in the following MIB objects of the PPVPN-MPLS-VPN-MIB as follows:
•
•
•
•
•
Examples
In the following example, MPLS VPN trap notifications are sent to the host specified as 172.31.156.34 using the community string named public if a VRF transitions from a down state to an up state or from an up state to a down state:
Router(config)# snmp-server enable traps mpls vpn vrf-up vrf-downRouter(config)# snmp-server host 172.31.156.34 traps public mpls-vpnRelated Commands
snmp-server enable traps pim
To enable Protocol Independent Multicast (PIM) Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps pim command in global configuration mode. To disable PIM-specific SNMP notifications, use the no form of this command.
snmp-server enable traps pim [neighbor-change | rp-mapping-change | invalid-pim-message]
no snmp-server enable traps pim
Syntax Description
Defaults
SNMP notifications are disabled by default.
Command Modes
Global configuration
Command History
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests for the specified notification types. PIM notifications are defined in the CISCO-PIM-MIB.my and PIM-MIB.my files, available from the Cisco MIB web site on Cisco.com at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
Examples
The following example shows how to configure a router to generate notifications indicating that a PIM interface of the router has been enabled:
! Configure PIM traps to be sent as SNMPv2c traps to host with IP address 10.0.0.1.Router(config)# snmp-server host 10.0.0.1 traps version 2c public pim! Configure router to send the neighbor-change class of notifications to host.Router(config)# snmp-server enable traps pim neighbor-change! Enable PIM sparse-dense mode on Ethernet interface 0/0.Router(config)# interface ethernet0/0Router(config-if)# ip pim sparse-dense-modeRelated Commands
snmp-server enable traps pppoe
To enable Point-to-Point Protocol over Ethernet (PPPoE) session count Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps pppoe command in global configuration mode. To disable PPPoE session count SNMP notifications, use the no form of this command.
snmp-server enable traps pppoe
no snmp-server enable traps pppoe
Syntax Description
This command has no arguments or keywords.
Defaults
SNMP notifications are disabled by default.
Command Modes
Global configuration
Command History
12.2(1)DC
This command was introduced.
12.2(8)T
This command was integrated into Cisco IOS Release 12.2(8)T.
Usage Guidelines
This command enables SNMP traps only. It does not support inform requests.
To configure the PPPoE session-count thresholds at which SNMP notifications will be sent, use the pppoe limit max-sessions or pppoe max-sessions commands.
For a complete description of this notification and additional MIB functions, see the CISCO-PPPOE-MIB.my file, available on Cisco.com at http://www.cisco.com/public/mibs/v2/.
Examples
The following example enables the router to send PPPoE session-count SNMP notifications to the host at the address 10.64.131.20:
snmp-server community public RWsnmp-server enable traps pppoesnmp-server host 10.64.131.20 version 2c public udp-port 1717Related Commands
snmp-server enable traps repeater
To enable or disable standard repeater (hub) Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps repeater command in global configuration mode. To disable repeater notifications, use the no form of this command.
snmp-server enable traps repeater [health] [reset]
no snmp-server enable traps repeater [health] [reset]
Syntax Description
Defaults
SNMP notifications are disabled by default.
If no option keywords are specified when entering this command, all repeater notifications available on your system are enabled or disabled.
Command Modes
Global configuration
Command History
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests.
This command controls (enables or disables) Repeater MIB notifications, as defined in RFC 1516. RFC 1516 defines objects for managing IEEE 802.3 10 Mbps baseband repeaters, also known as hubs.
There are two sets of notifications available for this command. The following notification is defined in the CISCO-REPEATER-MIB (enterprise 1.3.6.1.4.1.9.9.22.3):
•
The following notifications are defined in the CISCO-REPEATER-MIB-V1SMI (enterprise 1.3.6.1.2.1.22):
•
•
•
For a complete description of the repeater notifications and additional MIB functions, refer to the CISCO-REPEATER-MIB.my and CISCO-REPEATER-MIB-V1SMI.my files, available on Cisco.com at http://www.cisco.com/public/mibs/.
The snmp-server enable traps repeater command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. To send SNMP notifications, you must configure at least one snmp-server host command.
Examples
The following example enables the router to send repeater inform notifications to the host at the address myhost.cisco.com using the community string defined as public:
Router(config)# snmp-server enable traps repeaterRouter(config)# snmp-server host myhost.cisco.com informs version 2c publicRelated Commands
snmp-server host
Specifies the recipient of an SNMP notification operation.
snmp-server trap-source
Specifies the interface that an SNMP trap should originate from.
snmp-server enable traps rtr
To enable the sending of Service Assurance Agent (SAA) Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps rtr command in global configuration mode. To disable SAA SNMP notifications, use the no form of this command.
snmp-server enable traps rtr
no snmp-server enable traps rtr
Syntax Description
This command has no arguments or keywords.
Defaults
SNMP notifications are disabled by default.
Command Modes
Global configuration
Command History
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests.
This command controls (enables or disables) Cisco Service Assurance Agent notifications, as defined in the Response Time Monitor MIB (CISCO-RTTMON-MIB). The Service Assurance Agent was previously called the Response Time Reporter (RTR); the RTR syntax is retained in this command.
This command enables the following notifications:
•
•
•
•
For a complete description of these notification types, and for information about the other MIB functions, see the CISCO-RTTMON-MIB.my file, available through the Cisco TAC SNMP Object Navigator tool at http://www.cisco.com/go/mibs . For further information about the SAA, see the Network Monitoring Using the Cisco Service Assurance Agent document at http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/ffun_c/fcfprt3/fcf017.htm.
The snmp-server enable traps syslog command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. To send SNMP notifications, you must configure at least one snmp-server host command.
Examples
The following example enables the router to send SAA related informs to the host at the address myhost.cisco.com using the community string defined as public:
Router(config)# snmp-server enable traps rtrRouter(config)# snmp-server host myhost.cisco.com informs version 2c public rtrRelated Commands
snmp-server enable traps snmp
To enable the sending of RFC 1157 Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps snmp command in global configuration mode. To disable RFC 1157 SNMP notifications, use the no form of this command.
snmp-server enable traps snmp [authentication] [linkup] [linkdown] [coldstart] [warmstart]
no snmp-server enable traps snmp [authentication] [linkup] [linkdown] [coldstart] [warmstart]
Syntax Description
Defaults
SNMP notifications are disabled by default.
If you enter this command with none of the optional keywords, all RFC 1157 SNMP notifications are enabled (or disabled, if using the no form).
Command Modes
Global configuration
Command History
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests for the specified notification types.
If you do not enter an snmp-server enable traps snmp command, no notifications controlled by this command are sent. In order to configure the router to send these SNMP notifications, you must enter at least one snmp-server enable traps snmp command. If you enter the command with no keywords, all notification types are enabled. If you enter the command with a keyword, only the notification type related to that keyword is enabled.
The snmp-server enable traps snmp command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. In order to send notifications, you must configure at least one snmp-server host command.
For a host to receive a notification controlled by this command, both the snmp-server enable traps command and the snmp-server host command for that host must be enabled. If the notification type is not controlled by this command, just the appropriate snmp-server host command must be enabled.
The snmp-server enable traps snmp [ linkup] [linkdown] form of this command globally enables or disables SNMP linkUp and linkDown traps. After enabling either of these traps globally, you can disable these traps on specific interfaces using the no snmp trap link-status command in interface configuration mode. Note that on the interface level, linkUp and linkDown traps are enabled by default. This means that you do not have to enable these notifications on a per-interface basis. However, linkUp and linkDown notifications will not be sent unless you enable them globally using the snmp-server enable traps snmp command.
Examples
The following example enables the router to send all traps to the host myhost.cisco.com, using the community string defined as public:
Router(config)# snmp-server enable traps snmpRouter(config)# snmp-server host myhost.cisco.com public snmpThe following example enables the router to send all inform notifications to the host myhost.cisco.com using the community string defined as public:
Router(config)# snmp-server enable traps snmpRouter(config)# snmp-server host myhost.cisco.com informs version 2c public snmpThe following example shows the enabling all SNMP trap types, then the disabling of only the linkUp and linkDown trap:
Router> enablePassword:Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# snmp-server enable traps snmpRouter(config)# endRouter# more system:running-config | include traps snmpsnmp-server enable traps snmp authentication linkup linkdown coldstart warmstartRouter# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# no snmp-server enable traps snmp linkup linkdownRouter(config)# endRouter# more system:running-config | include traps snmpsnmp-server enable traps snmp authentication coldstart warmstartRelated Commands
snmp-server enable traps srp
To enable the sending of Intelligent Protection Switching (IPS) Spatial Reuse Protocol (SRP) Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps srp command in global configuration mode. To disable SRP notifications, use the no form of this command.
snmp-server enable traps srp
no snmp-server enable traps srp
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
Usage Guidelines
The Cisco SRP MIB module (CISCO-SRP-MIB.my) provides objects for monitoring IP-over-SONET IPS SRP traffic using the SNMP. When IPS is enabled, if a node or fiber facility failure is detected, traffic going toward or coming from the failure direction is wrapped (looped) back to go in opposite direction on the other ring.
The snmp-server enable traps srp command enables SRP state change notifications (traps or informs). SRP state change notifications are generated whenever one of the two sides of an SRP interface ring enters or leaves the wrapped state (when a ring wraps, or when a ring is restored).
Specifically, the srpMACIpsWrapCounter object in the CISCO-SRP-MIB increments when a Ring wraps, and the value of the rpMACIpsLastUnWrapTimeStamp object changes when a ring unwraps. (An "unwrap" event happens when the original ring is restored.)
The snmp-server enable traps srp command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. To send SNMP notifications, you must configure at least one snmp-server host command.
Examples
In the following example, SRP-specific informs are enabled and will be sent to the host "myhost.cisco.com" using the community string defined as public:
Router(config)# snmp-server enable traps srpRouter(config)# snmp-server host myhost.cisco.com informs version 2c public srpsnmp-server enable traps syslog
To enable the sending of system logging message Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps syslog command in global configuration mode. To disable system logging message SNMP notifications, use the no form of this command.
snmp-server enable traps syslog
no snmp-server enable traps syslog
Syntax Description
This command has no arguments or keywords.
Defaults
SNMP notifications are disabled by default.
Command Modes
Global configuration
Command History
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests.
This command controls (enables or disables) system logging message notifications. System logging messages (also called system error messages, or syslog messages) are status notification messages that are generated by the routing device during operation. These messages are typically logged to a destination (such as the terminal screen, to a system buffer, or to a remote "syslog" host).
If your software image supports the Cisco Syslog MIB, these messages can also be sent via SNMP to a network management station (NMS). To determine which software images support the Cisco Syslog MIB, used the Cisco MIB Locator tool at http://www.cisco.com/go/mibs/ .(At the time of writing, the Cisco Syslog MIB is only supported in "Enterprise" images.)
Unlike other logging processes on the system, debug messages (enabled using CLI debug commands) are not included with the logging messages sent via SNMP.
To specify the severity level at which notifications should be generated, use the logging history global configuration command. For additional information about the system logging process and severity levels, see the description of the logging commands.
The syslog notification is defined by the clogMessageGenerated NOTIFICATION-TYPE object in the Cisco Syslog MIB (CISCO-SYSLOG-MIB.my). When a syslog message is generated by the device a clogMessageGenerated notification is sent to the designated NMS. The clogMessageGenerated notification includes the following objects: clogHistFacility, clogHistSeverity, clogHistMsgName, clogHistMsgText, clogHistTimestamp.
For a complete description of these objects and additional MIB information, see the text of CISCO-SYSLOG-MIB.my, available on Cisco.com using the SNMP Object Navigator tool at http://www.cisco.com/go/mibs . See also the CISCO-SYSLOG-EXT-MIB and the CISCO-SYSLOG-EVENT-EXT-MIB.
The snmp-server enable traps syslog command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. To send SNMP notifications, you must configure at least one snmp-server host command.
Examples
The following example enables the router to send system logging messages at severity levels 0 (emergencies) through 2 (critical) to the host at the address myhost.cisco.com using the community string defined as public:
Router(config)# snmp-server enable traps syslogRouter(config)# logging history 2Router(config)# snmp-server host myhost.cisco.com traps version 2c publicRelated Commands
snmp-server enable traps voice poor-qov
To enable poor quality of voice Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps voice poor-qov command in global configuration mode. To disable poor quality of voice SNMP notifications, use the no form of this command.
snmp-server enable traps voice poor-qov
no snmp-server enable traps voice poor-qov
Syntax Description
This command has no arguments or keywords.
Defaults
SNMP notifications are disabled by default.
Command Modes
Global configuration
Command History
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests.
This command controls (enables or disables) poor-quality-of-voice notifications. The poor-quality-of-voice notification is defined in CISCO-VOICE-DIAL-CONTROL-MIB as follows:
enterprise 1.3.6.1.4.1.9.9.63.2
(1) cvdcPoorQoVNotification
For a complete description of this notification and additional MIB functions, see the CISCO-VOICE-DIAL-CONTROL-MIB.my file, available on Cisco.com at http://www.cisco.com/public/mibs/v2/.
The snmp-server enable traps voice poor-qov command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. To send SNMP notifications, you must configure at least one snmp-server host command.
Examples
The following example enables the router to poor-quality-of-voice informs to the host at the address myhost.cisco.com using the community string defined as public:
Router(config)# snmp-server enable traps voice poor-qovRouter(config)# snmp-server host myhost.cisco.com informs version 2c publicRelated Commands
snmp-server host
Specifies the recipient of an SNMP notification operation.
snmp-server trap-source
Specifies the interface that an SNMP trap should originate from.
snmp-server engineID local
To specify the Simple Network Management Protocol (SNMP) engine ID on the local device, use the snmp-server engineID local command in global configuration mode. To remove the configured engine ID, use the no form of this command.
snmp-server engineID local engineid-string
no snmp-server engineID local engineid-string
Syntax Description
engineid-string
The character string that identifies the engine ID. Consists of up to 24 characters.
Defaults
An SNMP engine ID is generated automatically but is not displayed or stored in the running configuration. You can display the default or configured engine ID by using the show snmp engineID EXEC command.
Command Modes
Global configuration
Command History
Usage Guidelines
The SNMP engine ID is a unique string used to identify the device for administration purposes. You do not need to specify an engine ID for the device; a default string is generated using Cisco's enterprise number (1.3.6.1.4.1.9) and the mac address of the first interface on the device. For further details on the SNMP engine ID, see RFC 2571.
If you wish to specify your own ID, note that you need not specify the entire 24-character engine ID if it contains trailing zeros. Specify only the portion of the Engine ID up until the point where only zeros remain in the value. For example, to configure an engine ID of 123400000000000000000000, you can specify snmp-server engineID local 1234.
Changing the value of snmpEngineID has important side-effects. A user's password (entered on the command line) is converted to an MD5 or SHA security digest. This digest is based on both the password and the local engine ID. The command line password is then destroyed, as required by RFC 2274. Because of this deletion, if the local value of engineID changes, the security digests of SNMPv3 users will be invalid, and the users will have to be reconfigured.
Similar restrictions require the reconfiguration of community strings when the engine ID changes. A remote engine ID is required when an SNMPv3 inform is configured. The remote engine ID is used to compute the security digest for authenticating and encrypting packets sent to a user on the remote host.
Related Commands
snmp-server engineID remote
To specify the Simple Network Management Protocol (SNMP) engine ID of a remote SNMP device, use the snmp-server engineID remote command in global configuration mode. To remove the configured engine ID, use the no form of this command.
snmp-server engineID remote ip-address [udp-port udp-port-number] [vrf vrf-name] engineid-string
no snmp-server engineID remote ip-address [udp-port udp-port-number] [vrf vrf-name] engineid-string
Syntax Description
Defaults
UDP port: 161
Command Modes
Global configuration
Command History
12.0(3)T
This command was introduced.
12.2(2)T
The vrf keyword and vrf-name argument were introduced.
Usage Guidelines
You need not specify the entire 24-character engine ID if it contains trailing zeros. Specify only the portion of the engine ID up until the point where only zeros remain in the value. For example, to configure an engine ID of 123400000000000000000000, you can specify the value 1234 as the engineid-string.
A remote engine ID is required when an SNMP version 3 inform is configured. The remote engine ID is used to compute the security digest for authenticating and encrypting packets sent to a user on the remote host.
Examples
The following example specifies the SNMP engine ID and configures the VRF name traps-vrf for SNMP communications with the remote device at 172.16.20.3:
Router(config)# snmp-server engineID remote 172.16.20.3 vrf traps-vrf 80000009030000B064EFE100Related Commands
snmp-server group
To configure a new Simple Network Management Protocol (SNMP) group, or a table that maps SNMP users to SNMP views, use the snmp-server group command in global configuration mode. To remove a specified SNMP group, use the no form of this command.
snmp-server group group-name {v1 | v2c | v3 {auth | noauth | priv}} [read read-view] [write write-view] [notify notify-view ] [access access-list]
no snmp-server group
Syntax Description
Defaults
Table 124 describes default values for the different views.
Command Modes
Global configuration
Command History
Usage Guidelines
When a community string is configured internally, two groups with the name public are autogenerated, one for the v1 security model and the other for the v2c security model. Similarly, deleting a community string will delete a v1 group with the name public and a v2c group with the name public.
Configuring Notify Views
Do not specify a notify view when configuring an SNMP group for the following reasons:
•
•
The notifyview option is available for two reasons:
•
•
Instead of specifying the notify view for a group as part of the snmp-server group command, use the following commands in global configuration mode:
Working with Passwords and Digests
No default values exist for authentication or privacy algorithms when you configure the command. Also, no default passwords exist. The minimum length for a password is one character, although Cisco recommends using eight characters for security. If you forget a password, you cannot recover it and will need to reconfigure the user. You can specify either a plain-text password or a localized MD5 digest.
The following example shows how to enter a plain-text password for the string arizona2 for user John in group Johngroup, type the following command line:
snmp-server user John Johngroup v3 auth md5 arizona2When you enter a show running-config command, you will not see a line for this user. To see if this user has been added to the configuration, type the show snmp user command.
If you have the localized MD5 or SHA digest, you can specify that string instead of the plain-text password. The digest should be formatted as aa:bb:cc:dd where aa, bb, and cc are hex values. Also, the digest should be exactly 16 octets long.
The following example shows how to specify the command with a digest name of 00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:
Router(config)# snmp-server user John Johngroup v3 encrypted auth md5 00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FFRelated Commands
show snmp group
Displays the names of groups on the router and the security model, the status of the different views, and the storage type of each group.
snmp-server host
To specify the recipient of a Simple Network Management Protocol (SNMP) notification operation, use the snmp-server host command in global configuration mode. To remove the specified host from the configuration, use the no form of this command.
snmp-server host {hostname | ip-address} [vrf vrf-name] [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type]
no snmp-server host {hostname | ip-address} [vrf vrf-name] [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type]
Syntax Description
Command Default
This command is disabled. No notifications are sent.
If you enter this command with no keywords, the default is to send all trap types to the host. No informs will be sent to the host.
The no snmp-server host command with no keywords disables traps, but not informs, to the host. To disable informs, use the no snmp-server host informs command.
Note
Command Modes
Global configuration
Command History
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. Traps are unreliable because the receiver does not send acknowledgments when it receives traps. The sender cannot determine if the traps were received. However, a SNMP entity that receives an inform request acknowledges the message with a SNMP response protocol data unit (PDU). If the sender never receives the response, the inform request can be sent again. Thus, informs are more likely to reach their intended destination.
Compared to traps, informs consume more resources in the agent and in the network. Unlike a trap, which is discarded as soon as it is sent, an inform request must be held in memory until a response is received or the request times out. Also, traps are sent only once; an inform may be retried several times. The retries increase traffic and contribute to a higher overhead on the network.
If you do not enter a snmp-server host command, no notifications are sent. To configure the router to send SNMP notifications, you must enter at least one snmp-server host command. If you enter the command with no keywords, all trap types are enabled for the host.
To enable multiple hosts, you must issue a separate snmp-server host command for each host. You can specify multiple notification types in the command for each host.
When multiple snmp-server host commands are given for the same host and kind of notification (trap or inform), each succeeding command overwrites the previous command. Only the last snmp-server host command will be in effect. For example, if you enter an snmp-server host inform command for a host and then enter another snmp-server host inform command for the same host, the second command will replace the first.
The snmp-server host command is used in conjunction with the snmp-server enable command. Use the snmp-server enable command to specify which SNMP notifications are sent globally. For a host to receive most notifications, at least one snmp-server enable command and the snmp-server host command for that host must be enabled.
Some notification types cannot be controlled with the snmp-server enable command. For example, some notification types are always enabled and others are enabled by a different command. For example, the linkUpDown notifications are controlled by the snmp trap link-status command. These notification types do not require an snmp-server enable command.
A notification-type option's availability depends on the router type and Cisco IOS software features supported on the router. For example, the envmon notification type is available only if the environmental monitor is part of the system. To see what notification types are available on your system, use the command help ? at the end of the snmp-server host command.
The vrf keyword allows you to specify the notifications being sent to a specified IP address over a specific VRF. The VRF defines a VPN membership of a customer so data is stored using the VPN.
The @ symbol is used as a delimiter between the community string and the context in which it is used. For example, specific VLAN information in BRIDGE-MIB may be polled using community@VLAN_ID (for example, public@100) where 100 is the VLAN number. Avoid using the @ symbol as part of the SNMP community string when configuring this command.
Regarding Notification-Type Keywords
The notification-type keywords used in the snmp-server host command do not always match the keywords used in the corresponding snmp-server enable traps command. For example, the notification keyword applicable to Multiprotocol Label Switching Protocol (MPLS) traffic engineering tunnels is specified as mpls-traffic-eng (containing two hyphens and no intervening spaces). The corresponding parameter in the snmp-server enable traps command is specified as mpls-traffic-eng (containing an intervening space and a hyphen).
This syntax difference is necessary to ensure that the command-line interface (CLI) interprets the notification-type keyword of the snmp-server host command as a unified, single-word construct, which preserves the capability of the snmp-server host command to accept multiple notification-type keywords in the command line. The snmp-server enable traps commands, however, often use two-word constructs to provide hierarchical configuration options and to maintain consistency with the command syntax of related commands. Table 125 maps some examples of snmp-server enable traps commands to the keywords used in the snmp-server host command.
Table 125 Notification Keywords and Corresponding SNMP Enable Traps Commands
snmp-server enable traps l2tun session
l2tun-session
snmp-server enable traps mpls ldp
mpls-ldp
snmp-server enable traps mpls traffic-eng1
mpls-traffic-eng
snmp-server enable traps mpls vpn
mpls-vpn
1 See the Cisco IOS Multiprotocol Label Switching Command Reference for documentation of this command.
Examples
If you want to configure a unique SNMP community string for traps but prevent SNMP polling access with this string, the configuration should include an access list. The following example shows how to name a community string comaccess and number an access list 10:
Router(config)# snmp-server community comaccess ro 10Router(config)# snmp-server host 172.20.2.160 comaccessRouter(config)# access-list 10 deny any
Note
The following example shows how to send RFC 1157 SNMP traps to a host specified named myhost.cisco.com. Other traps are enabled, but only SNMP traps are sent because only snmp is specified in the snmp-server host command. The community string is defined as comaccess.
Router(config)# snmp-server enable trapsRouter(config)# snmp-server host myhost.cisco.com comaccess snmpThe following example shows how to send the SNMP and Cisco environmental monitor enterprise-specific traps to address 172.30.2.160 using the community string public:
Router(config)# snmp-server enable traps snmpRouter(config)# snmp-server enable traps envmonRouter(config)# snmp-server host 172.30.2.160 public snmp envmonThe following example shows how to enable the router to send all traps to the host myhost.cisco.com using the community string public:
Router(config)# snmp-server enable trapsRouter(config)# snmp-server host myhost.cisco.com publicThe following example will not send traps to any host. The BGP traps are enabled for all hosts, but only the ISDN traps are enabled to be sent to a host. The community string is defined as public.
Router(config)# snmp-server enable traps bgpRouter(config)# snmp-server host myhost.cisco.com public isdnThe following example shows how to enable the router to send all inform requests to the host myhost.cisco.com using the community string public:
Router(config)# snmp-server enable trapsRouter(config)# snmp-server host myhost.cisco.com informs version 2c publicThe following example shows how to send HSRP MIB informs to the host specified by the name myhost.cisco.com. The community string is defined as public.
Router(config)# snmp-server enable traps hsrpRouter(config)# snmp-server host myhost.cisco.com informs version 2c public hsrpThe following example shows how to send all SNMP notifications to company.com over the VRF named trap-vrf using the community string public:
Router(config)# snmp-server host company.com vrf trap-vrf publicThe following example shows how to configure an IPv6 SNMP notification server with the IPv6 address 2001:0DB8:0000:ABCD:1 using the community string public:
Router(config)# snmp-server host 2001:0DB8:0000:ABCD:1 version 2c public udp-port 2012The following example shows how to specify VRRP as the protocol using the community string public:
Router(config)# snmp-server enable traps vrrpRouter(config)# snmp-server host myhost.cisco.com traps version 2c public vrrpRelated Commands
snmp-server informs
To specify inform request options, use the snmp-server informs command in global configuration mode. To return the settings to the defaults, use the no form of this command.
snmp-server informs [retries retries] [timeout seconds] [pending pending]
no snmp-server informs [retries retries] [timeout seconds] [pending pending]
Syntax Description
Defaults
Inform requests are resent three times. Informs are resent after 30 seconds if no response is received. The maximum number of informs waiting for acknowledgments at any one time is 25.
Command Modes
Global configuration
Command History
Examples
The following example increases the pending queue size if you are seeing a large number of inform drops:
snmp-server informs pending 50The following example increases the default timeout if you are sending informs over slow network links. Because informs will be sitting in the queue for a longer period of time, you may also need to increase the pending queue size.
snmp-server informs timeout 60 pending 40The following example decreases the default timeout if you are sending informs over very fast links:
snmp-server informs timeout 5The following example increases the retry count if you are sending informs over unreliable links. Because informs will be sitting in the queue for a longer period of time, you may need to increase the pending queue size.
snmp-server informs retries 10 pending 45Related Commands
snmp-server location
To set the system location string, use the snmp-server location command in global configuration mode. To remove the location string, use the no form of this command.
snmp-server location text
no snmp-server location
Syntax Description
Defaults
No system location string is set.
Command Modes
Global configuration
Command History
Examples
The following example shows how to set a system location string:
snmp-server location Building 3/Room 214Related Commands
snmp-server manager session-timeout
To set the amount of time before a nonactive session is destroyed, use the snmp-server manager session-timeout command in global configuration mode. To return the value to its default, use the no form of this command.
snmp-server manager session-timeout seconds
no snmp-server manager session-timeout
Syntax Description
Defaults
Idle sessions time out after 600 seconds (10 minutes).
Command Modes
Global configuration
Command History
Usage Guidelines
Sessions are created when the SNMP manager in the router sends SNMP requests, such as inform requests, to a host or receives SNMP notifications from a host. One session is created for each destination host. If there is no further communication between the router and host within the session timeout period, the session will be deleted.
The router tracks statistics, such as the average round-trip time required to reach the host, for each session. Using the statistics for a session, the SNMP manager in the router can set reasonable timeout periods for future requests, such as informs, for that host. If the session is deleted, all statistics are lost. If another session with the same host is later created, the request timeout value for replies will return to the default value.
However, sessions consume memory. A reasonable session timeout value should be large enough such that regularly used sessions are not prematurely deleted, yet small enough such that irregularly used, or one-shot sessions, are purged expeditiously.
Examples
The following example sets the session timeout to a larger value than the default:
snmp-server managersnmp-server manager session-timeout 1000Related Commands
show snmp pending
Displays the current set of pending SNMP requests.
show snmp sessions
Displays the current SNMP sessions.
snmp-server manager
Starts the SNMP manager process.
snmp-server manager
To start the Simple Network Management Protocol (SNMP) manager process, use the snmp-server manager command in global configuration mode. To stop the SNMP manager process, use the no form of this command.
snmp-server manager
no snmp-server manager
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
Global configuration
Command History
Usage Guidelines
The SNMP manager process sends SNMP requests to agents and receives SNMP responses and notifications from agents. When the SNMP manager process is enabled, the router can query other SNMP agents and process incoming SNMP traps.
Most network security policies assume that routers will be accepting SNMP requests, sending SNMP responses, and sending SNMP notifications. With the SNMP manager functionality enabled, the router may also be sending SNMP requests, receiving SNMP responses, and receiving SNMP notifications. The security policy implementation may need to be updated prior to enabling this functionality.
SNMP requests are typically sent to UDP port 161. SNMP responses are typically sent from UDP port 161. SNMP notifications are typically sent to UDP port 162.
Examples
The following example enables the SNMP manager process:
snmp-server managerRelated Commands
snmp-server packetsize
To establish control over the largest Simple Network Management Protocol (SNMP) packet size permitted when the SNMP server is receiving a request or generating a reply, use the snmp-server packetsize command in global configuration mode. To restore the default value, use the no form of this command.
snmp-server packetsize byte-count
no snmp-server packetsize
Syntax Description
Defaults
1500 bytes
Command Modes
Global configuration
Command History
Examples
The following example establishes a packet filtering of a maximum size of 1024 bytes:
snmp-server packetsize 1024Related Commands
snmp-server queue-length
Establishes the message queue length for each trap host.
snmp-server queue-length
To establish the message queue length for each trap host, use the snmp-server queue-length command in global configuration mode.
snmp-server queue-length length
Syntax Description
length
Integer that specifies the number of trap events that can be held before the queue must be emptied.
Defaults
10 events
Command Modes
Global configuration
Command History
Usage Guidelines
This command defines the length of the message queue for each trap host. Once a trap message is successfully transmitted, software will continue to empty the queue, but never faster than at a rate of four trap messages per second.
During device bootup, there is a possibility that some traps could be dropped because of trap queue overflow on the device. If you suspect this is occurring, you can increase the size of the trap queue (for example, to 100) to determine if traps are then able to be sent during bootup.
Examples
In the following example, the SNMP notification queue is increased to 50 events:
Router(config)# snmp-server queue-length 50Related Commands
snmp-server packetsize
Establishes control over the largest SNMP packet size permitted when the SNMP server is receiving a request or generating a reply.
snmp-server system-shutdown
To use the Simple Network Management Protocol (SNMP) message reload feature, the router configuration must include the snmp-server system-shutdown command in global configuration mode. To prevent an SNMP system-shutdown request (from an SNMP manager) from resetting the Cisco agent, use the no form of this command.
snmp-server system-shutdown
no snmp-server system-shutdown
Syntax Description
This command has no arguments or keywords.
Defaults
This command is not included in the configuration file.
Command Modes
Global configuration
Command History
Examples
The following example enables the SNMP message reload feature:
snmp-server system-shutdownsnmp-server tftp-server-list
To limit the TFTP servers used via Simple Network Management Protocol (SNMP) controlled TFTP operations (saving and loading configuration files) to the servers specified in an access list, use the snmp-server tftp-server-list command in global configuration mode. To disable this function, use the no form of this command.
snmp-server tftp-server-list number
no snmp-server tftp-server-list
Syntax Description
Defaults
Disabled
Command Modes
Global configuration
Command History
Examples
The following example limits the TFTP servers that can be used for configuration file copies via SNMP to the servers in access list 44:
snmp-server tftp-server-list 44snmp-server trap link
To enable linkUp/linkDown Simple Network Management Protocol (SNMP) traps that are compliant with RFC2233, use the snmp-server trap link command in global configuration mode. To disable IETF- compliant functionality and revert to the default Cisco implementation of linkUp/linkDown traps, use the no form of this command.
snmp-server trap link ietf
no snmp-server trap link ietf
Syntax Description
Defaults
This command is disabled by default.
Command Modes
Global configuration
Command History
Usage Guidelines
The snmp-server trap link ietf command is used to configure your router to use the RFC2233 IETF standards-based implementation of linkUp/linkDown traps. This command is disabled by default to allow you to continue using the earlier Cisco implementation of linkUp/linkDown traps if you so choose.
However, please note that when using the default Cisco object definitions, linkUp/linkDown traps are not generated correctly for sub-interfaces. In the default implementation an arbitrary value is used for the locIfReason object in linkUp/linkDown traps for sub-interfaces, which may give you unintended results. This is because the locIfReason object is not defined for sub-interfaces in the current Cisco implementation, which uses OLD-CISCO-INTERFACES-MIB.my.
If you do not enable this functionality, the link trap varbind list will consist of {ifIndex, ifDescr, ifType, locIfReason}. After you enable this functionality with the snmp-server trap link ietf command, the varbind list will consist of {inIndex, ifAdminStatus,ifOperStatus, if Descr, ifType}. The locIfReason object will also be conditionally included in this list depending on whether meaningful information can be retrieved for that object. A configured sub-interface will generate retrievable information. On non-HWIDB interfaces, there will be no defined value for locIfReason, so it will be omitted from the trap message.
Examples
The following example shows the enabling of the RFC 2233 linkUp/linkDown traps, starting in privileged EXEC mode:
Router# config termEnter configuration commands, one per line. End with CNTL/Z.Router(config)# snmp-server trap link ietfRouter(config)# endRouter# more system:running config...!snmp-server engineID local 00000009000000A1616C2056snmp-server community public ROsnmp-server community private RWsnmp-server trap link ietf!...Related Commands
debug snmp packets
Displays information about every SNMP packet sent or received by the router for the purposes of troubleshooting.
snmp-server trap-authentication
The snmp-server trap-authentication command has been replaced by the snmp-server enable traps snmp authentication command. See the description of the snmp-server enable traps snmp command in this chapter for more information.
snmp-server trap-source
To specify the interface (and hence the corresponding IP address) that a Simple Network Management Protocol (SNMP) trap should originate from, use the snmp-server trap-source command in global configuration mode. To remove the source designation, use the no form of the command.
snmp-server trap-source interface
no snmp-server trap-source
Syntax Description
interface
Interface from which the SNMP trap originates. The argument includes the interface type and number in platform-specific syntax (for example, type/slot/port).
Defaults
No interface is specified.
Command Modes
Global configuration
Command History
Usage Guidelines
When an SNMP trap or inform is sent from a Cisco SNMP server, it has a notification address of whatever interface it happened to go out of at that time. Use this command to monitor notifications from a particular interface.
Examples
The following example specifies that the IP address for Ethernet interface 0 is the source for all SNMP notifications:
Router(config)# snmp-server trap-source ethernet 0The following example specifies that the IP address for the Ethernet interface in slot2, port 1 is the source for all SNMP notifications:
Router(config)# snmp-server trap-source ethernet 2/1Related Commands
snmp-server enable traps
Enables a router to send SNMP traps and informs.
snmp-server host
Specifies the recipient of an SNMP notification operation.
snmp-server trap-timeout
To define how often to try resending trap messages on the retransmission queue, use the snmp-server trap-timeout command in global configuration mode.
snmp-server trap-timeout seconds
Syntax Description
seconds
Integer that sets the interval (in seconds) for resending the messages. The default is 30 seconds.
Defaults
30 seconds
Command Modes
Global configuration
Command History
Usage Guidelines
Before the Cisco IOS software tries to send a trap, it looks for a route to the destination address. If there is no known route, the trap is saved in a retransmission queue. The snmp server trap-timeout command determines the number of seconds between retransmission attempts.
Examples
The following example sets an interval of 20 seconds to try resending trap messages on the retransmission queue:
snmp-server trap-timeout 20Related Commands
snmp-server host
Specifies the recipient of an SNMP notification operation.
snmp-server queue-length
Establishes the message queue length for each trap host.
snmp-server user
To configure a new user to a Simple Network Management Protocol (SNMP) group, use the snmp-server user command in global configuration mode. To remove a user from an SNMP group, use the no form of the command.
snmp-server user username group-name [remote host [udp-port port]] {v1 | v2c | v3 [encrypted] [auth {md5 | sha} auth-password]} [access access-list]
no snmp-server user
Syntax Description
Defaults
Table 126 describes default behaviors for encryption, passwords and access lists.
Command Modes
Global configuration
Command History
Usage Guidelines
To configure a remote user, specify the IP address or port number for the remote SNMP agent of the device where the user resides. Also, before you configure remote users for a particular agent, configure the SNMP engine ID, using the command snmp-server engineID with the remote option. The remote agent's SNMP engine ID is needed when computing the authentication/privacy digests from the password. If the remote engine ID is not configured first, the configuration command will fail.
SNMP passwords are localized using the SNMP engine ID of the authoritative SNMP engine. For informs, the authoritative SNMP agent is the remote agent. You need to configure the remote agent's SNMP engine ID in the SNMP database before you can send proxy requests or informs to it.
Related Commands
show snmp user
Displays information on each SNMP username in the group username table.
snmp-server view
To create or update a view entry, use the snmp-server view command in global configuration mode. To remove the specified Simple Network Management Protocol (SNMP) server view entry, use the no form of this command.
snmp-server view view-name oid-tree {included | excluded}
no snmp-server view view-name
Syntax Description
Defaults
No view entry exists.
Command Modes
Global configuration
Command History
Usage Guidelines
Other SNMP commands require a view as an argument. You use this command to create a view to be used as arguments for other commands that create records including a view.
Two standard predefined views can be used when a view is required, instead of defining a view. One is everything, which indicates that the user can see all objects. The other is restricted, which indicates that the user can see three groups: system, snmpStats, and snmpParties. The predefined views are described in RFC 1447.
The first snmp-server command that you enter enables both versions of SNMP.
Examples
The following example creates a view that includes all objects in the MIB-II subtree:
snmp-server view mib2 mib-2 includedThe following example creates a view that includes all objects in the MIB-II system group and all objects in the Cisco enterprise MIB:
snmp-server view phred system includedsnmp-server view phred cisco includedThe following example creates a view that includes all objects in the MIB-II system group except for sysServices (System 7) and all objects for interface 1 in the MIB-II interfaces group:
snmp-server view agon system includedsnmp-server view agon system.7 excludedsnmp-server view agon ifEntry.*.1 includedRelated Commands
snmp-server community
Sets up the community access string to permit access to the SNMP protocol.
sntp broadcast client
To use the Simple Network Time Protocol (SNTP) to accept Network Time Protocol (NTP) traffic from any broadcast server, use the sntp broadcast client command in global configuration mode to configure a Cisco 1003, Cisco 1004, Cisco 1005, Cisco 1600, Cisco 1720, or Cisco 1750 router. To prevent the router from accepting broadcast traffic, use the no form of this command.
sntp broadcast client
no sntp broadcast client
Syntax Description
This command has no arguments or keywords.
Defaults
The router does not accept SNTP traffic from broadcast servers.
Command Modes
Global configuration
Command History
Usage Guidelines
SNTP is a compact, client-only version of the NTP. SNMP can only receive the time from NTP servers; it cannot be used to provide time services to other systems.
SNTP typically provides time within 100 milliseconds of the accurate time, but it does not provide the complex filtering and statistical mechanisms of NTP. In addition, SNTP does not authenticate traffic, although you can configure extended access lists to provide some protection.
You must configure the router with either this command or the sntp server global configuration command to enable SNTP.
Examples
The following example enables the router to accept broadcast NTP packets and shows sample show sntp command output:
Router(config)# sntp broadcast clientRouter(config)# endRouter#%SYS-5-CONFIG: Configured from console by consoleRouter# show sntpSNTP server Stratum Version Last Receive172.21.28.34 4 3 00:00:36 Synced BcastBroadcast client mode is enabled.Related Commands
sntp server
To configure a Cisco 800, Cisco 1003, Cisco 1004, Cisco 1005, Cisco 1600, Cisco 1720, or Cisco 1750 router to use the Simple Network Time Protocol (SNTP) to request and accept Network Time Protocol (NTP) traffic from a stratum 1 time server, use the sntp server command in global configuration mode. To remove a server from the list of NTP servers, use the no form of this command.
sntp server {address | hostname} [version number]
no sntp server {address | hostname}
Syntax Description
address
IP address of the time server.
hostname
Host name of the time server.
version number
(Optional) Version of NTP to use. The default is 1.
Defaults
The router does not accept SNTP traffic from a time server.
Command Modes
Global configuration
Command History
Usage Guidelines
SNTP is a compact, client-only version of the NTP. SNMP can only receive the time from NTP servers; it cannot be used to provide time services to other systems.
SNTP typically provides time within 100 milliseconds of the accurate time, but it does not provide the complex filtering and statistical mechanisms of NTP. In addition, SNTP does not authenticate traffic, although you can configure extended access lists to provide some protection.
Enter this command once for each NTP server.
You must configure the router with either this command or the sntp broadcast client global configuration command in order to enable SNTP.
SNTP time servers should operate only at the root (stratum 1) of the subnet, and then only in configurations where no other source of synchronization other than a reliable radio or modem time service is available. A stratum 2 server cannot be used as an SNTP time server. The use of SNTP rather than NTP in primary servers should be carefully considered.
Examples
The following example enables the router to request and accept NTP packets from the server at 172.21.118.9 and displays sample show sntp command output:
Router(config)# sntp server 172.21.118.9Router(config)# endRouter#%SYS-5-CONFIG: Configured from console by consoleRouter# show sntpSNTP server Stratum Version Last Receive172.21.118.9 5 3 00:01:02 SyncedRelated Commands
special-character-bits
To configure the number of data bits per character for special characters such as software flow control characters and escape characters, use the special-character-bits command in line configuration mode. To restore the default value, use the no form of this command.
special-character-bits {7 | 8}
no special-character-bits
Syntax Description
7
Selects the 7-bit ASCII character set. This is the default.
8
Selects the full 8-bit character set for special characters.
Defaults
7-bit ASCII character set
Command Modes
Line configuration
Command History
Usage Guidelines
Setting the special character bits to 8 allows you to use twice as many special characters as with the 7-bit ASCII character set. The special characters affected by this setting are the escape, hold, stop, start, disconnect, and activation characters.
Examples
The following example allows the full 8-bit international character set for special characters on line 5:
Router(config)# line 5Router(config-line)# special-character-bits 8Related Commands
squeeze
To permanently erase files tagged as "deleted" or "error" on Class A Flash file systems, use the squeeze command in EXEC mode.
squeeze [/nolog] [/quiet] filesystem:
Syntax Description
Command Modes
EXEC
Command History
Usage Guidelines
When Flash memory is full, you might need to rearrange the files so that the space used by the files marked "deleted" can be reclaimed. (This "squeeze" process is required for linear Flash memory cards to make sectors contiguous; the free memory must be in a "block" to be usable.)
When you enter the squeeze command, the router copies all valid files to the beginning of Flash memory and erases all files marked "deleted." After the squeeze process is completed, you can write to the reclaimed Flash memory space.
Caution
In addition to removing deleted files, the squeeze command removes any files that the system has marked as "error". An error file is created when a file write fails (for example, the device is full). To remove error files, you must use the squeeze command.
Rewriting Flash memory space during the squeeze operation may take several minutes.
Using the /nolog keyword disables the log for the squeeze process. In most cases this will speed up the squeeze process. However, if power is lost or the Flash card is removed during the squeeze process, all the data on the Flash card will be lost, and the device will have to be reformatted.
Note
Using the /quiet keyword disables the output of status messages to the console during the squeeze process.
If the optional keywords are not used, the progress of squeeze process will be displayed to the console, a log for the process will be maintained, and the squeeze process is interruptible.
On Cisco 2600 or Cisco 3600 series routers, the entire file system needs to be erased once before the squeeze command can be used. After being erased once, the squeeze command should operate properly on the Flash file system for the rest of the Flash file system's history.
To erase an entire flash file system on a Cisco 2600 or 3600 series router, perform the following steps:
Step 1
Step 2
Examples
In the following example, the file named config1 is deleted, and then the squeeze command is used to reclaim the space used by that file. The /nolog option is used to speed up the squeeze process.
Router# delete config1Delete filename [config1]?Delete slot0:conf? [confirm]Router# dir slot0:! Note that the deleted file name appears in square bracketsDirectory of slot0:/1 -rw- 4300244 Apr 02 2001 03:18:07 c7200-boot-mz.122-0.142 -rw- 2199 Apr 02 2001 04:45:15 [config1]3 -rw- 4300244 Apr 02 2001 04:45:23 image20578304 bytes total (11975232 bytes free)!20,578,304 - 4,300,244 - 4,300,244 - 2,199 - 385 = 11975232Router# squeeze /nolog slot0:%Warning: Using /nolog option would render squeeze operation uninterruptible.All deleted files will be removed. Continue? [confirm]Squeeze operation may take a while. Continue? [confirm]Squeeze of slot0 completed in 291.832 secs .Router# dir slot0:Directory of slot0:/1 -rw- 4300244 Apr 02 2001 03:18:07 c7200-boot-mz.122-0.142 -rw- 4300244 Apr 02 2001 04:45:23 image20578304 bytes total (11977560 bytes free)!20,578,304 - 4,300,244 - 4,300,244 - 256 = 11977560Related Commands
delete
Deletes a file on a Flash memory device.
dir
Displays a list of files on a file system.
undelete
Recovers a file marked "deleted" on a Class A or Class B Flash file system.
state-machine
To specify the transition criteria for the state of a particular state machine, use the state-machine command in global configuration mode. To remove a particular state machine from the configuration, use the no form of this command.
state-machine name state first-character last-character [next-state | transmit]
no state-machine name
Syntax Description
Defaults
No transition criteria are specified.
Command Modes
Global configuration
Command History
Usage Guidelines
This command is paired with the dispatch-machine line configuration command, which defines the line on which the state machine is effective.
Examples
In the following example a dispatch machine named "function" is configured to ensure that the function key characters on an ANSI terminal are kept in one packet. Because the default in the example is to remain in state 0 without sending anything, normal key signals are sent immediately.
Router(config)# line 1 20Router(config-line)# dispatch-machine functionRouter(config-line)# exitRouter(config)# state-machine function 0 0 255 transmitRelated Commands
statistics-distribution-interval
To set the time interval for each statistics distribution kept for the Service Assurance Agent (SAA), use the statistics-distribution-interval command in SAA RTR configuration mode. To return to the default value, use the no form of this command.
statistics-distribution-interval milliseconds
no statistics-distribution-interval
Syntax Description
milliseconds
Number of milliseconds (ms) used for each statistics distribution kept. The default is 20 ms.
Defaults
20 ms
Command Modes
SAA RTR configuration
Command History
Usage Guidelines
In most situations, you do not need to change the statistical distribution interval or size. Only change the interval or size when distributions are needed, for example, when performing statistical modeling of your network. To set the statistical distributions size, use the distributions-of-statistics-kept SAA RTR configuration command.
Examples
In the following example, the distribution is set to five and the distribution interval is set to 10 ms. This means that the first distribution will contain statistics from 0 to 9 ms, the second distribution will contain statistics from 10 to 19 ms, the third distribution will contain statistics from 20 to 29 ms, the fourth distribution will contain statistics from 30 to 39 ms, and the fifth distribution will contain statistics from 40 ms to infinity.
Router(config)# rtr 1Router(config-rtr)# type echo protocol ipIcmpEcho 172.28.161.21Router(config-rtr)# distribution-of-statistics-kept 5Router(config-rtr)# statistics-distribution-interval 10Related Commands
