Managing and understanding system logs
The Blue Cedar Connect Gateway maintains a set of logging information for troubleshooting purposes. These logs are helpful for Blue Cedar Technical Support to diagnose any issues with the gateway.
This section describes the CLI commands and options to configure what information is logged and where it goes.
Enabling logging on the gateway
In configuration mode, use the following CLI command to enable/disable the logging service on the gateway:
% set system logging enable true/false
By default, logging on the gateway is enabled (true).
Example:
% set system logging enable true
% commit
Commit succeeded.
% show system logging
logging {
enable true;
}
Configuring the logs by class and severity
In configuration mode, use the following command-line template to filter the logs by class and by severity. This set command determines which log events are saved; use the log show commands described in Viewing and filtering logs to retrieve logs based on a variety of filters.
% set system logging name_of_class [severity level target target1,target2 |
subclass subclass_id severity level]
Option | Description |
---|---|
name_of_class | The element of the gateway to log. Possible values:
|
subclass subclass_id | Optional. A subclass identifier to use for filtering the class into subsets. |
severity level | Optional. The minimum severity level reported. Possible values, in order of decreasing severity.
|
target target1,target2 | Optional. One or more locations to send logging information. Possible values:
Note: When specifying multiple locations for the target, no space is allowed right after the comma. If there is a space after the comma, the command fails and the gateway gives you an "invalid element in path (name_of_element) error". |
Examples
In this example, the CLI command sets the class ike with a log severity of warning and target output syslog and log. The following show command verifies the setting:
% set system logging ike severity warning target syslog,log
% commit
Commit succeeded.
% show system logging ike
ike {
severity warning;
target syslog,log;
}
In this example, the CLI command sets the class ike with a subclass 2 and a debug level of severity. The following show command verifies the setting:
% set system logging ike subclass 2 severity debug
% commit
Commit succeeded.
% show system logging ike
ike {
severity warning;
target syslog,log;
subclass 2 {
severity debug;
}
}
Turning off logging for a specific class
When you want to turn off the filtering of logging messages for a specific class, use one of the following CLI commands:
% set system logging classname severity off
% delete system logging
classname
severity
To turn logging back on for any class, set the severity to the desired level of logging (critical, major, minor, warning, informational, or debug).
Example 1
This example uses the show command to display the gateway's current severity for the aaa logging class, then turns off the severity filter (to stop logging aaa messages, no matter what severity level). The show command then validates that the severity filter was changed:
% show system logging aaa
aaa {
severity informational;
target log,syslog;
}
% set system logging aaa severity off
% commit
Commit succeeded.
% show system logging aaa
aaa {
target log,syslog;
severity off;
}
Example 2
The show command outputs the gateway's current severity for the aaa logging class, then the delete command turns off the severity logging, and the show command validates that the severity state was changed:
% show system logging aaa severity
severity informational;
% delete system logging aaa severity
% commit
Commit succeeded.
% show system logging aaa
aaa {
target log,syslog;
severity off;
}
Viewing the configured rules for logging
After you configure the settings on the gateway for logging information, you can check to see if those logging settings (or "rules") were deployed on the gateway.
Use the following command line to check if the deployed operational data for logging matches the configured data:
> show status operational context default system-operational services log-rules
This command helps troubleshoot any difference between the configured logging rules and the deployed configuration data that the gateway is running on. If the data does not match, then there is an issue in how the log rule was created. If the log that you configured does not exist, then perform these steps:
Check the configuration parameters to make sure the log is set up.
If the log exists in the configuration, then check the operational data using the above command to ensure that the logging rule is registered with the gateway.
Example of showing logging rules
> show status operational context default system-operational services log-rules
log-rules AAA {
class-name AAA,AAACL;
action Enable;
target "Log,System Log";
severity Informational,Warning,Minor,Major,Critical;
}
log-rules AMF {
class-name AMFAGENT,AMFAPI,AMFMGR;
action Enable;
target "Log,System Log";
severity Informational,Warning,Minor,Major,Critical;
}
log-rules CFM {
class-name CFM,CFMCL;
action Enable;
target "Log,System Log";
severity Informational,Warning,Minor,Major,Critical;
}
log-rules DATAPATH {
class-name DATAPATH,DPCL;
action Enable;
target "Log,System Log";
severity Informational,Warning,Minor,Major,Critical;
}
log-rules IKE {
class-name IKE,IKECL;
action Enable;
target "Log,System Log";
severity Informational,Warning,Minor,Major,Critical;
}
log-rules IKE_SUB_999 {
class-name IKE,IKECL;
action Enable;
subclass-id 999;
target "Log,System Log";
severity Debug,Informational,Warning,Minor,Major,Critical;
}
log-rules INTFMGR {
class-name INTFMGR,INTFMGRCL;
action Enable;
target Log;
severity Informational,Warning,Minor,Major,Critical;
}
log-rules IPSEC {
class-name IPSEC;
action Enable;
target "Log,System Log";
severity Informational,Warning,Minor,Major,Critical;
}
log-rules IPSEC_SUB_999 {
class-name IPSEC;
action Enable;
subclass-id 999;
target "Log,System Log";
severity Debug,Informational,Warning,Minor,Major,Critical;
}
log-rules POLICY {
class-name POLICY;
action Enable;
target "Log,System Log";
severity Informational,Warning,Minor,Major,Critical;
}
log-rules REPORTMGR {
class-name REPORTMGR;
action Enable;
target "Log,System Log";
severity Informational,Warning,Minor,Major,Critical;
}
log-rules SERVICES-LOGS {
action Enable;
subclass-id 999;
target "Log,System Log";
severity Debug,Informational,Warning,Minor,Major,Critical;
}
log-rules POLICY {
class-name POLICY;
action Enable;
target "Log,System Log";
severity Informational,Warning,Minor,Major,Critical;
}
log-rules REPORTMGR {
class-name REPORTMGR;
action Enable;
target "Log,System Log";
severity Informational,Warning,Minor,Major,Critical;
}
log-rules SERVICES-LOGS {
class-name SERVICES,SERVICESCL,LAUNCHER;
action Enable;
target "Log,System Log";
severity Informational,Warning,Minor,Major,Critical;
}