Debug/Syslog Operation > Logging command

  

 next

Logging command

At the global configuration level, the loggingcommand allows you to enable debug logging on specified syslog servers and select a subset of Event Log messages to send for debugging purposes according to:

  • Severity level

  • System module

By specifying both a severity level and system module, you can use both configured settings to filter the Event Log messages you want to use to troubleshoot switch or network error conditions.
[CAUTION: ]

CAUTION: After you configure a syslog server and a severity level and/or system module to filter the Event Log messages that are sent, if you save these settings to the startup configuration file by entering the write memory command, these debug and logging settings are automatically re-activated after a switch reboot or power recycle. The debug settings and destinations configured in your previous troubleshooting session will then be applied to the current session, which may not be desirable.

After a reboot, messages remain in the Event Log and are not deleted. However, after a power recycle, all Event Log messages are deleted.

If you configure a severity level, system module, or both to temporarily filter Event Log messages, be sure to reset the values to their default settings by entering the no form of the following commands to ensure that Event Log messages of all severity levels and from all system modules are sent to configured syslog servers:

HP Switch(config)# no logging severity<div>


[ 
debug  |   
major  |   
error  |   
warning  |   
info ]</div>
HP Switch(config)# no logging system-module 


system-module

Configuring a syslog server

Syslog is a client-server logging tool that allows a client switch to send event notification messages to a networked device operating with syslog server software. Messages sent to a syslog server can be stored to a file for later debugging analysis.

To use the syslog feature, you must install and configure a syslog server application on a networked host accessible to the switch. For instructions, see the documentation for the syslog server application.

To configure a syslog service, use the logging syslog-ip-addr command as shown below.

When you configure a syslog server, Event Log messages are automatically enabled to be sent to the server. To reconfigure this setting, use the following commands:

To display the currently configured syslog servers as well as the types of debug messages and the severity-level and system-module filters used to specify the Event Log messages that are sent, enter the show debug command (See Debug/syslog configuration commands.)

Syntax:

[no] logging syslog-ip-addr

Enables or disables syslog messaging to the specified IP address. You can configure up to six addresses. If you configure an address when none are already configured, this command enables destination logging (syslog) and the Event debug type. Therefore, at a minimum, the switch begins sending Event Log messages to configured syslog servers. The ACL, IP-OSPF, and/or IP-RIP message types are also sent to the syslog servers if they are currently enabled as debug types. (See "Debug Messages".)

no logging

Removes all currently configured syslog logging destinations from the running configuration.

Using this form of the command to delete the only remaining syslog server address disables debug destination logging on the switch, but the default Event debug type does not change.

no logging syslog-ip-address

Removes only the specified syslog logging destination from the running configuration.

Removing all configured syslog destinations with the no logging command (or a specified syslog server destination with the no logging syslog-ip-address command) does not delete the syslog server IP addresses stored in the startup configuration.

Deleting syslog addresses in the startup configuration

Enter a no logging command followed by the write memory command.

Verifying the deletion of a syslog server address

Display the startup configuration by entering the show config command.

Blocking the messages sent to configured syslog servers from the currently configured debug message type

Enter the no debug debug-type command.

Disabling syslog logging on the switch without deleting configured server addresses

Enter the no debug destination logging command. Note that, unlike the case in which no syslog servers are configured, if one or more syslog servers are already configured and syslog messaging is disabled, configuring a new server address does not re-enable syslog messaging. To re-enable syslog messaging, you must enter the debug destination logging command.

Sending logging messages using TCP

Syntax:

[ no ] logging ip-addr [ udp 1024-49151 | tcp 1024-49151 ]

Allows the configuration of the UDP or TCP transport protocol for the transmission of logging messages to a syslog server.

Specifying a destination port with UDP or TCP is optional.

Default ports: UDP port is 514

TCP port is 1470

Default Transport Protocol: UDP

Because TCP is a connection-oriented protocol, a connection must be present before the logging information is sent. This helps ensure that the logging message will reach the syslog server. Each configured syslog server needs its own connection. You can configure the destination port that is used for the transmission of the logging messages.

Examples:

Configuring TCP for logging message transmission using the default port

Configuring TCP for logging message transmission using the default port

Configuring TCP for logging message transmission using a specified port

Configuring TCP for logging message transmission using a specified port

Configuring UDP for logging message transmission using the default port

Configuring UDP for logging message transmission using the default port

Configuring UDP for logging message transmission using a specified port

Configuring UDP for logging message transmission using a specified port

Syntax:

[ no ] logging facility facility-name

The logging facility specifies the destination subsystem used in a configured syslog server. (All configured syslog servers must use the same subsystem.) HP recommends the default (user) subsystem unless your application specifically requires another subsystem. Options include:

user

(default) Random user-level messages

kern

Kernel messages

mail

Mail system

daemon

System daemons

auth

Security/authorization messages

syslog

Messages generated internally by syslog

lpr

Line-printer subsystem

news

Netnews subsystem

uucp

uucp subsystem

cron

cron/at subsystem

sys9

cron/at subsystem

sys10 - sys14

Reserved for system use

local10 - local17

Reserved for system use

Use the no form of the command to remove the configured facility and reconfigure the default (user) value.

Disable linkup/down syslog messages based on port

This feature provides a per-port basis filter that can restrict the logging of events that are associated with a link status change. Unimportant linkup/linkdown events can be filtered out, avoiding unwanted messages in the event log and reducing troubleshooting time.

The specific port-based events to be controlled are:

RMON_PMGR_PORT_UP—Indicates that the port has changed from and off-line to an on-line state. To be online the port must be both connected to the LAN and enabled through configuration.

RMON_PMGR_PORT_DOWN—Indicates that the port has changed from an on-line state to an offline state. For this state to occur, the port is physically disconnected from the LAN, disabled through the configuration, or both.

The following rules apply:

  • Only one filter can be enabled at a time.

  • The maximum number of configured filters is 10.

  • A filter is identified by a unique name of up to 16 printable ASCII characters.

  • Filters can be dynamically replaced; the newly enabled filter automatically disables the previous filter.

  • A filter always contains a default sub-filter that functions as the filtering rules terminator.

  • To apply filtering to an event logging process, the filter must be explicitly enabled from the CLI.

  • Enabled filter modules can be dynamically modified; the changes will take effect immediately.

A filter module may include up to 19 option sub-filters and a default sub-filter. The sub-filter types are:

  • Severity—checks the severity level of the event log message. The severity values are:

    • major

    • warning

    • error

    • info

    • debug

  • Event number—Checks the event number of the event log message.

  • Regular expression—Checks everything beyond the date/time portion of the event log message.

A sub-filter has a sequence number, criteria to be matched, and a resulting action when a match occurs. All of the parameters must be specified in order to create the sub-filter.

  • Sequence number: Used for the ordering of sub-filters. Range 1-98.

  • Matching criteria: Can be the severity level, event number, or a regular expression.

  • Action to execute: When a match occurs, the resulting action is either permit the logging of the event, or deny the logging of the event.

The following sub-filter rules apply:

  • Up to 19 optional sub-filters and a default sub-filter are allowed in a filter module.

  • Sub-filters in the filter module can be of the same or different types.

  • Sub-filter entries can be modified with new criteria and action definitions.

  • Sub-filters are executed from the lowest sequence number to the highest. As soon as a match is found the log event is immediately accepted or rejected and no further matching operation is performed.

  • The default sub-filter must always be the last entry in a filter module. It functions as the rules terminator when the criteria matching performed by the prior sub-filters in a filter does not produce an action.

  • The default sub-filter cannot be deleted, re-ordered, or changed. The only parameter that can be modified is the action parameter of permit or deny. The default is permit.

Creating a filter

Syntax:

[no] logging filter <name> <sequence> [severity <severity> | event-num <num> | <regexp>] [permit | deny]

Creates a logging filter to restrict which events are logged. The no form of the command removes the logging filter.

<name>: The name that identifies the filter.

severity <severity>: Specifies the severity of an event—major, warning, error, info, or debug.

event-num <num>: Specifies an event number to match.

deny: If the log entry matches the specified criteria, do not log the event message. No further criteria are evaluated for a match.

permit: If the log entry matches the specified criteria, log the event message. No further criteria are evaluated for a match.

Enabling a filter after creation

Syntax:

[no] logging filter <name> enable | disable

Enables a log filter. Only one filter can be enabled at a time. An enabled filter automatically disables a previously enabled filter.

<name>: The name that identifies the filter.

Clearing a filter

Syntax:

clear logging filter <name | all>

Clears statistics counters for the named logging filter or for all filters.

Viewing filter configuration information

Syntax:

show logging filter <name>

Displays the logging filter’s configuration information. The Matches column indicates the number of times that criteria have matched.

Example:

Specifying the criteria for a filter and then enabling the filter

Specifying the criteria for a filter and then enabling the filter

  1. The filter named SevWarnFatal adds a sub-filter of the severity type, with a sequence number of 10. The sub-filter specifies that a match for an event log message with a severity of “warning” will be logged.

  2. The second sub-filter has a sequence number of 20 and a severity type of major. The sub-filter specifies that a match for an event log message with a severity of “major” will be logged.

  3. The default sub-filter, which is created automatically at the time of filter creation, is always the last entry in the filter module. It matches “anything” and cannot be changed. You can change the actions to either permit or deny. This example specifies that any message that did not meet the prior matching criteria will not be logged.

  4. The last command enables the filter named SevWarnFatal. If there was another filter enabled, this filter automatically replaces it and the other filter is disabled.

Example:

Specifying the criteria for a filter named noUpDownEvents and then enabling the filter

Specifying the criteria for a filter named noUpDownEvents and then enabling the filter

  1. The filter named noUpDownEvents adds a sub-filter with a type of event-num, and a sequence number of 10. The sub-filter specifies that a match for an event log message with an event number of “76” will not be logged.

  2. The second sub-filter has a sequence number of 20 and a type of event-num. The sub-filter specifies that a match for an event log message with an event number of “77” will not be logged.

  3. The default sub-filter, which is created automatically at the time of filter creation, is always the last entry in the filter module. It matches “anything” and cannot be changed. You can change the actions to either permit or deny. This example specifies that any message that did not meet the prior matching criteria will be logged.

  4. The last command enables the filternamednoUpDownEvents. If there was another filter enabled, this filter automatically replaces it and the other filter is disabled.

Example:

Specifying the criteria for a match using a regular expression and then enabling the filter

Specifying the criteria for a match using a regular expression and then enabling the filter

This example denies logging of the matching regular expression “port <port-num> is now on-line” for ports A10, A22, and B5.

  1. The filter named noUpPorts adds a sub-filter with a type of regular expression for ports A10, A22, and B5. The sub-filter specifies the matching criteria for the regular expression and if there is a match, the event log message is not logged.

  2. The default sub-filter specifies that any message that did not meet the prior matching criteria will be logged.

  3. The last command enables the filter named noUpPorts.

Example:

Specifying the criteria for a match using a regular expression for specific ports

Specifying the criteria for a match using a regular expression for specific ports

  1. The filter named noStpBlockPorts adds a sub-filter with a type of regular expression with a sequence number of 10. This rule specifies that event messages from ports A1-A10, and B1-B4 with the “.*Blocked by STP” expression pattern in the message body are logged.

  2. The second command adds a sub-filter with a type of regular expression and a sequence number of 20. This rule specifies that event messages generated from any ports with the “.*Blocked by STP” expression pattern in the message body are not logged.

  3. The default sub-filter specifies that any message that did not meet the prior matching criteria will be logged.

  4. The last command enables the filter named noStpBlockPorts.

Output examples:

The following example displays the show command output for displaying the configured logging filters.

The configured logging filters

The configured logging filters

The following example displays the output when specific filters are specified.

Output for specified logging filters

Output for specified logging filters

The following example displays the running-config output.

Output of running-config file

Output of running-config file

prev

 

up

 next

Debug command 

home

 Adding a description for a Syslog server

Copyright © 2014 Hewlett-Packard Development Company, L.P.