Courseiva
SystemGlobal Config

snmp-server enable traps

Enables SNMP trap notifications on the device, allowing it to send alerts to an SNMP manager for specified events.

Definition: snmp-server enable traps is a Cisco IOS global config command. Enables SNMP trap notifications on the device, allowing it to send alerts to an SNMP manager for specified events.

Overview

The `snmp-server enable traps` command is a fundamental configuration directive in Cisco IOS that activates the device's ability to generate and send SNMP trap notifications to designated SNMP managers. SNMP (Simple Network Management Protocol) traps are unsolicited messages sent by a network device to a Network Management Station (NMS) to alert it of significant events, such as interface state changes, authentication failures, or environmental thresholds. This command is essential for proactive network monitoring, as it enables real-time event notification without requiring the NMS to poll the device continuously.

Without traps, the NMS must rely on periodic polling, which can miss transient issues and increase network overhead. The command operates at the global configuration level and, by itself, enables all available trap types. However, administrators typically pair it with specific trap subtypes (e.g., `snmp-server enable traps snmp linkdown`) to limit notifications to relevant events.

This command is part of a broader SNMP configuration workflow that includes setting the SNMP community string (or SNMPv3 user), defining the trap destination with `snmp-server host`, and optionally tuning trap queues and throttling. In Cisco IOS, the command modifies the running configuration immediately and is saved to the startup configuration upon `write memory`. It requires privilege level 15 (enable mode) to configure.

The command's impact is significant: enabling traps can increase CPU utilization if too many events are triggered, so careful selection of trap types is advised. Alternatives include using SNMP informs (acknowledged traps) or syslog messages, but traps remain the standard for real-time SNMP-based alerting. Understanding this command is critical for CCNA and CCNP candidates, as SNMP is a core network management protocol covered extensively in the exams.

Syntax·Global Config
snmp-server enable traps

When to Use This Command

  • Enable traps to monitor interface up/down events for network troubleshooting.
  • Configure traps for authentication failures to detect unauthorized access attempts.
  • Enable cold start traps to notify the NMS after a device reboot.
  • Enable link status traps to track changes in network connectivity.

Parameters

ParameterSyntaxDescription
notification-typeWORD (e.g., snmp, interface, bgp, ospf, etc.)Specifies the type of SNMP notification to enable. If omitted, all trap types are enabled. Common values include 'snmp' for SNMP-specific traps, 'interface' for interface state changes, 'bgp' for BGP events, 'ospf' for OSPF events, and 'environment' for environmental monitoring. Use '?' to see available options. A common mistake is enabling all traps without considering the impact on CPU and NMS load.

Command Examples

Enable all SNMP traps

snmp-server enable traps

This command enables all available SNMP traps on the device. No output is generated; use 'show snmp' to verify.

Enable specific traps

snmp-server enable traps snmp authentication linkdown linkup

Enables only authentication failure, link down, and link up traps. No output; verify with 'show snmp'.

Understanding the Output

The command does not produce output. To verify trap configuration, use 'show snmp' and look for 'Traps enabled' line. For example: 'Traps enabled: snmp authentication linkdown linkup coldstart warmstart'.

Each listed trap indicates it is active. Missing traps mean they are not enabled. Ensure the NMS IP is configured with 'snmp-server host' to receive traps.

Configuration Scenarios

Enable SNMP Traps for Interface State Changes

A network administrator wants to receive immediate notifications when any interface on a router goes up or down, to quickly detect link failures.

Topology

R1(Gi0/0)---10.0.12.0/30---(Gi0/0)R2

Steps

  1. 1.Step 1: Enter global configuration mode: configure terminal
  2. 2.Step 2: Enable SNMP traps for interface events: snmp-server enable traps interface
  3. 3.Step 3: Set the SNMP community string (read-write): snmp-server community MyCommunity RW
  4. 4.Step 4: Specify the trap destination (NMS IP): snmp-server host 192.168.1.100 version 2c MyCommunity
  5. 5.Step 5: Exit configuration mode and save: end; write memory
Configuration
!
configure terminal
snmp-server enable traps interface
snmp-server community MyCommunity RW
snmp-server host 192.168.1.100 version 2c MyCommunity
end
write memory
!

Verify: Use 'show snmp pending' to verify no pending traps. Use 'debug snmp packets' to see trap generation when an interface is toggled. Expected output: SNMP trap packet sent to 192.168.1.100.

Watch out: If the NMS is not receiving traps, ensure the community string matches on both the router and NMS, and that UDP port 162 is not blocked by an ACL.

Enable SNMP Traps for BGP Neighbor Changes

An enterprise network uses BGP for external connectivity and needs to be alerted when BGP sessions go down or come up, to quickly react to routing issues.

Topology

R1(Gi0/0)---10.0.12.0/30---(Gi0/0)R2 (BGP peering between R1 and R2)

Steps

  1. 1.Step 1: Enter global configuration mode: configure terminal
  2. 2.Step 2: Enable BGP-specific SNMP traps: snmp-server enable traps bgp
  3. 3.Step 3: Configure SNMP community and trap host: snmp-server community TrapCommunity RO; snmp-server host 10.0.0.100 version 2c TrapCommunity
  4. 4.Step 4: Ensure BGP is configured and peering is established
  5. 5.Step 5: Exit and save: end; write memory
Configuration
!
configure terminal
snmp-server enable traps bgp
snmp-server community TrapCommunity RO
snmp-server host 10.0.0.100 version 2c TrapCommunity
end
write memory
!

Verify: Use 'show snmp trap' to see trap statistics. Simulate a BGP flap by clearing the BGP session: 'clear ip bgp *'. Check NMS for received traps. Use 'debug snmp packets' to confirm trap transmission.

Watch out: BGP traps are only generated if BGP is configured and the session state changes. Ensure the NMS is reachable and that the SNMP version matches (v2c or v3).

Troubleshooting with This Command

When troubleshooting SNMP trap issues, the first step is to verify that the `snmp-server enable traps` command is present in the running configuration. Use `show running-config | include snmp-server` to confirm. If traps are not being received, check the trap destination with `show snmp host`.

The output should list the configured NMS IP, version, and community. If the destination is missing or incorrect, reconfigure with `snmp-server host`. Next, examine trap statistics using `show snmp trap`.

This command displays counters for traps sent, failed, and queued. A high 'failed' count indicates network issues or NMS unavailability. Use `show snmp pending` to see if traps are queued due to a slow NMS.

If the queue is growing, consider increasing the trap queue length with `snmp-server trap-queue-length`. For specific trap types, use `debug snmp packets` to see trap generation in real time. This debug output shows the trap OID, source, and destination.

Be cautious with debug on production devices. Common symptoms include: no traps received at NMS – check ACLs blocking UDP 162; traps received but not processed – verify community string and SNMP version match; high CPU due to excessive traps – narrow the trap types enabled. Correlate with `show logging` for syslog messages that may indicate events that should trigger traps.

For example, if an interface goes down, a syslog message like '%LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to down' should appear. If no trap is sent, ensure `snmp-server enable traps interface` is configured. Additionally, use `show snmp community` to verify community strings and access rights.

If using SNMPv3, check user configuration with `show snmp user`. Finally, test connectivity from the router to the NMS using `ping` and `telnet` to port 162 (though telnet may not work if not listening). A step-by-step diagnostic flow: 1) Verify trap enablement. 2) Verify trap destination. 3) Check trap statistics. 4) Enable debug for a short period. 5) Simulate an event. 6) Analyze debug output. 7) Check NMS logs.

This systematic approach isolates the issue quickly.

CCNA Exam Tips

1.

CCNA exam may ask which command enables traps for authentication failures: 'snmp-server enable traps snmp authentication'.

2.

Remember that 'snmp-server enable traps' without keywords enables all traps, but you must also configure 'snmp-server host' to send them.

3.

The exam might test that traps are sent via UDP port 162 by default.

4.

Know that enabling traps does not require a reload; it takes effect immediately.

Common Mistakes

Forgetting to configure 'snmp-server host' after enabling traps, so traps are enabled but never sent.

Enabling all traps when only specific ones are needed, causing unnecessary NMS processing.

Typing 'snmp-server enable trap' (singular) instead of 'traps' (plural), which is incorrect.

snmp-server enable traps vs snmp-server host [ip] [string]

These two commands are commonly used together to enable SNMP notifications, but they serve distinct roles: one enables the trap generation globally, while the other specifies where to send those traps. Misunderstanding their interplay can lead to configuration errors.

Aspectsnmp-server enable trapssnmp-server host [ip] [string]
PurposeEnables trap generation for all eventsDefines the trap receiver host and community
PrerequisiteNone; can be configured independentlyRequires 'snmp-server enable traps' for traps to be sent
Effect on NotificationsCauses device to generate traps for enabled eventsDirects generated traps to a specific host
PersistencePersists in running-configPersists in running-config
Precedence/OverrideGlobal enable; can be refined with specific trap typesMultiple hosts supported; overrides no host config
Typical UseEarly step in SNMP configurationDefines one or more NMS destinations

Use snmp-server enable traps when you want the device to generate SNMP trap notifications for any configured events.

Use snmp-server host [ip] [string] when you need to specify the destination SNMP manager and community string for receiving those notifications.

Platform Notes

In IOS-XE, the `snmp-server enable traps` command behaves identically to classic IOS, but the output format of `show snmp trap` may include additional fields like 'Trap queue max size' and 'Trap queue current size'. IOS-XE also supports the `snmp-server enable traps snmp` suboptions for linkup/linkdown traps. For NX-OS, the equivalent command is `snmp-server enable traps` in global configuration mode, but the syntax for specific trap types differs.

For example, to enable interface traps on NX-OS, use `snmp-server enable traps interface`. NX-OS also uses `snmp-server host` with slightly different syntax: `snmp-server host <ip> traps version 2c <community>`. On ASA firewalls, SNMP trap configuration is done via `snmp-server enable traps` but the available trap types are limited (e.g., syslog, connection).

The ASA uses `snmp-server host <interface> <ip> community <community>` to set the trap destination. In IOS-XR, the command is `snmp-server traps` and the configuration is hierarchical. For example, to enable all traps: `snmp-server traps`.

To enable specific traps: `snmp-server traps interface`. IOS-XR also requires the `snmp-server host` command with a different syntax: `snmp-server host <ip> traps version 2c <community>`. Behavior differences across versions: In IOS 12.x, the command `snmp-server enable traps` without any keyword enables all traps, but in 15.x and later, it still enables all traps but the default set may vary.

Some older versions require explicit `snmp-server enable traps snmp` to enable standard SNMP traps. Always check the specific IOS version documentation.

Related Commands

snmp-server community [string] [ro|rw]

Configures an SNMP community string on a Cisco IOS device to allow SNMP access with read-only or read-write privileges for network monitoring and management.

snmp-server host [ip] [string]

Configures the SNMP server to send SNMP notifications (traps or informs) to a specified host, using a community string for authentication.

Practice for the CCNA 200-301

Test your knowledge with practice questions covering all CCNA 200-301 exam domains.

Practice CCNA 200-301 Questions