logging trap [level]
Configures the severity level for syslog messages sent to a remote syslog server, filtering which messages are forwarded based on their severity.
Definition: logging trap [level] is a Cisco IOS global config command. Configures the severity level for syslog messages sent to a remote syslog server, filtering which messages are forwarded based on their severity.
Overview
The `logging trap [level]` command is a global configuration command on Cisco IOS devices that controls which syslog messages are forwarded to a remote syslog server based on their severity level. Syslog is a standard protocol used for message logging, and Cisco devices generate syslog messages for various events such as interface state changes, configuration changes, errors, and security alerts. By default, the device logs messages to its internal buffer, but for centralized monitoring and long-term storage, you typically configure a remote syslog server.
The `logging trap` command sets a severity threshold: only messages at or below the specified level are sent to the remote server. For example, setting `logging trap 4` (warning) will send messages with severity 0 (emergencies) through 4 (warnings), but not messages with severity 5 (notifications) through 7 (debugging). This filtering is crucial in production networks to avoid overwhelming the syslog server with low-priority or debug messages, while ensuring critical events are captured.
The command works in conjunction with `logging host` (which specifies the remote server IP) and `logging source-interface` (which sets the source IP for syslog packets). It is important to note that the `logging trap` command only affects messages sent to the remote server; it does not change what is logged to the console, monitor, or buffer. Those destinations have their own severity filters (`logging console`, `logging monitor`, `logging buffered`).
When troubleshooting, you might use `logging trap debugging` (level 7) temporarily to send all messages to the server for analysis, but this should be used cautiously as it can generate high traffic and load on the server. The command is part of the broader syslog configuration workflow: first, enable logging globally with `logging on`, then specify the server with `logging host`, optionally set the source interface, and finally set the trap level. The command takes effect immediately and is saved to the running configuration.
There is no privilege level requirement beyond global configuration mode. One important behavior: if you do not specify a level, the default is `informational` (level 6). Also, if you use `logging trap` without a level, it sets the level to the default, which might not be what you intend.
Always explicitly set the level. The command is supported in all IOS versions, including IOS-XE, but in NX-OS the equivalent is `logging server severity`.
logging trap [level]When to Use This Command
- Reduce syslog server load by sending only warnings and above (levels 0-4) during normal operations.
- Enable debugging messages (level 7) temporarily to a syslog server for troubleshooting a specific issue.
- Comply with security policies by ensuring all critical (level 2) and higher messages are logged externally.
- Filter out informational messages (level 6) to avoid cluttering the syslog server with routine notifications.
Parameters
| Parameter | Syntax | Description |
|---|---|---|
| level | <0-7> or keyword (emergencies, alerts, critical, errors, warnings, notifications, informational, debugging) | Specifies the severity level threshold for syslog messages sent to the remote server. Valid values are 0 (emergencies) through 7 (debugging), or the corresponding keywords. Only messages with a severity level equal to or lower than this value are forwarded. Common mistake: using a higher number to mean more severe, but actually lower numbers are more critical. For example, level 0 is the most critical, level 7 is the least. Also, forgetting that the default is informational (6) if not specified. |
Command Examples
Set trap level to warnings and above
logging trap warningsNo output is generated; the command configures the trap level to 4 (warnings). Only syslog messages with severity 0-4 are sent to the configured syslog server.
Set trap level to debugging for troubleshooting
logging trap debuggingSets the trap level to 7 (debugging), allowing all syslog messages including debug output to be sent to the syslog server. Use with caution as it can generate high traffic.
Understanding the Output
This command does not produce output. To verify the configured trap level, use 'show logging'. In the output, look for 'Logging to: <server>' and the line 'Trap logging: level <severity>'.
The severity level is shown as a number (0-7) or name. Ensure the level matches your intended filtering. A common mistake is setting the level too low (e.g., debugging) causing excessive traffic, or too high (e.g., emergencies) missing important warnings.
Configuration Scenarios
Configure remote syslog server for critical events only
A network administrator wants to forward only emergency, alert, critical, and error messages (levels 0-3) to a central syslog server at 192.168.1.100 to reduce server load and focus on important events.
Topology
R1(Gi0/0)---192.168.1.0/24---Syslog Server (192.168.1.100)Steps
- 1.Step 1: Enter global configuration mode: Router> enable then Router# configure terminal
- 2.Step 2: Enable logging: Router(config)# logging on
- 3.Step 3: Specify the remote syslog server: Router(config)# logging host 192.168.1.100
- 4.Step 4: Set the trap level to errors (3): Router(config)# logging trap errors
- 5.Step 5: (Optional) Set the source interface for syslog packets: Router(config)# logging source-interface GigabitEthernet0/0
- 6.Step 6: Exit and verify: Router(config)# end
! Full IOS config block Router(config)# logging on Router(config)# logging host 192.168.1.100 Router(config)# logging trap errors Router(config)# logging source-interface GigabitEthernet0/0
Verify: Use `show logging` to verify the trap level. Look for line: 'Trap logging: level errors, 0 message lines logged'.
Watch out: If you forget to enable `logging on`, no syslog messages are sent even if the host and trap are configured. Also, ensure the syslog server is reachable and UDP port 514 is open.
Temporarily send all syslog messages for troubleshooting
During a network issue, an engineer needs to capture all syslog messages including debugging information to a remote server for analysis. After troubleshooting, the level should be restored to a less verbose setting.
Topology
R1(Gi0/0)---10.10.10.0/30---(Gi0/0)R2 (R2 is the syslog server)Steps
- 1.Step 1: Enter global configuration mode: Router> enable then Router# configure terminal
- 2.Step 2: Set trap level to debugging (7): Router(config)# logging trap debugging
- 3.Step 3: Verify the change: Router(config)# do show logging | include Trap logging
- 4.Step 4: After troubleshooting, reset to a lower level, e.g., notifications (5): Router(config)# logging trap notifications
- 5.Step 5: Exit: Router(config)# end
! Temporary change for troubleshooting Router(config)# logging trap debugging ! After troubleshooting, revert Router(config)# logging trap notifications
Verify: Use `show logging` to confirm the trap level changed. Also check the syslog server to see if messages are arriving.
Watch out: Setting trap level to debugging can generate a huge volume of traffic and fill up the syslog server disk quickly. Always revert after troubleshooting. Also, debug messages are only generated if `debug` commands are enabled; `logging trap debugging` does not enable debugging itself.
Troubleshooting with This Command
When troubleshooting syslog forwarding issues, the `logging trap` command is often the culprit if messages are not reaching the remote server. First, verify that logging is enabled globally with `show logging`. Look for the line 'Logging is enabled' or 'Logging is disabled'.
If disabled, use `logging on` to enable it. Next, check the trap level: 'Trap logging: level <level>'. If the level is set too high (e.g., critical or errors), lower-severity messages like notifications or informational will not be sent.
For example, if you expect to see interface up/down messages (severity 5, notifications), but the trap level is set to errors (3), those messages will be filtered out. To confirm, you can temporarily set the trap level to debugging (7) to see if messages start flowing; if they do, the issue is the threshold. Also, verify the remote host is configured correctly with `show logging | include Host`.
The output should list the syslog server IP and port (default 514). If the host is missing, use `logging host <ip>`. Another common issue is the source interface: if the router has multiple interfaces, syslog packets might be sourced from an unexpected interface, causing the server to reject them due to ACLs or routing issues.
Use `logging source-interface` to set a consistent source. Check connectivity from the router to the syslog server using `ping` and `telnet <ip> 514` (though telnet to UDP port won't work, but you can test with a TCP-based syslog if supported). Also, ensure the syslog server is listening on UDP 514 and that no firewall between them blocks the traffic.
On the server side, check if messages are being received; sometimes the server may have its own filtering. Correlate with other commands: `show logging` gives a summary of all logging destinations and their levels. Use `debug ip udp` with caution to see if syslog packets are being sent.
If messages are sent but not received, the problem is likely network or server configuration. If messages are not sent, check the trap level and logging enable state. Remember that `logging trap` only affects the remote server; console and buffer logging have separate filters.
So if you see messages on the console but not on the server, the trap level is the first thing to check.
CCNA Exam Tips
CCNA exam may ask which severity levels are included when you set 'logging trap warnings' (levels 0-4).
Remember that 'logging trap' only affects messages sent to syslog servers, not console or buffer logging.
The default trap level is 'informational' (level 6) if not configured.
Know the severity level numbers: emergencies (0), alerts (1), critical (2), errors (3), warnings (4), notifications (5), informational (6), debugging (7).
Common Mistakes
Setting trap level to 'debugging' and forgetting to disable it, causing high CPU and bandwidth usage.
Confusing 'logging trap' with 'logging console' or 'logging buffered' — they control different destinations.
Using a level name incorrectly (e.g., 'warning' instead of 'warnings') — the command accepts both singular and plural but 'warnings' is standard.
logging trap [level] vs logging host [ip]
These commands are often used together but serve distinct purposes: logging host defines the destination for syslog messages, while logging trap sets the severity threshold for messages forwarded to all remote hosts. Misunderstanding their roles can lead to incomplete or excessive logging.
| Aspect | logging trap [level] | logging host [ip] |
|---|---|---|
| Scope | Filters severity of messages sent to remote servers | Specifies IP address of remote syslog server |
| Configuration mode | Global configuration | Global configuration |
| Default | Default severity level is informational (6) | No default host; none configured |
| Effect | Controls which messages are forwarded | Defines where messages are sent |
| Interaction | Applies to all configured logging hosts | Independent; multiple hosts can be configured |
Use logging trap [level] when you need to reduce syslog traffic to remote servers by filtering out low-severity messages.
Use logging host [ip] when you need to send syslog messages to a specific remote server for centralized monitoring.
Platform Notes
In IOS-XE (e.g., Catalyst 9000 switches, ISR 4000 series), the `logging trap` command syntax and behavior are identical to classic IOS. However, IOS-XE uses a newer syslog implementation that may support additional features like structured syslog or RFC 5424 format, but the command itself remains the same. In NX-OS (e.g., Nexus switches), the equivalent command is `logging server severity <level>`, where level is specified as a number (0-7) or keyword.
For example, `logging server severity 3` sets the trap level to errors. NX-OS also uses `logging server <ip>` to specify the server. The default severity in NX-OS is 6 (informational).
On ASA firewalls, the command is `logging trap <level>` within the logging configuration, but ASA uses a different severity numbering (0-7 same as IOS). However, ASA also requires `logging enable` and `logging host <interface> <ip>`. In IOS-XR, the equivalent is `logging server <ip> severity <level>`, but IOS-XR uses a different configuration hierarchy (under `logging`).
Note that in older IOS versions (12.x), the default trap level was informational (6), but in newer versions (15.x and later), the default remains informational unless changed. There is no difference in syntax between 12.x and 15.x for this command. Always check the specific platform documentation, but the command is widely consistent across Cisco platforms.
Related Commands
logging host [ip]
Configures the router to send syslog messages to a remote syslog server at the specified IP address for centralized logging and monitoring.
show logging
Displays the state of system logging (syslog) on the device, including buffer contents, logging configuration, and statistics, used for troubleshooting and monitoring system events.
Practice for the CCNA 200-301
Test your knowledge with practice questions covering all CCNA 200-301 exam domains.
Practice CCNA 200-301 Questions