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
BASH


By default, logging on the gateway is enabled (true).  

Example:

% set system logging enable true 
% commit 
Commit succeeded. 
% show system logging 
logging { 
 enable true; 
}
BASH


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]
BASH


OptionDescription
name_of_class  

The element of the gateway to log. Possible values:

  • aaa
  • amf
  • cfm
  • datapath
  • ike
  • intfmgr
  • ipsec
  • policy
  • reportmgr
  • services-logs
subclass subclass_idOptional. A subclass identifier to use for filtering the class into subsets.
severity levelOptional. The minimum severity level reported. Possible values, in order of decreasing severity.
  • critical: Log errors of the highest severity only.
  • major: Log errors of serious severity (as well as critical).
  • minor: Log all errors (minor, major, critical).
  • warning: Log potential errors as well as errors.
  • informational: Log information about the status of the gateway, as well as warnings and errors.
  • debug: Log all information about the gateway
target target1,target2

Optional. One or more locations to send logging information. Possible values:

  • log: The logs are sent to a file on the gateway that is used to store the logging information locally. When you perform a "command diagnostics collect" command, it collects these log files.
  • syslog: The logs are sent to the configured syslog servers as specified with "set system syslog..."
  • console: The logs are sent directly to the terminal session of the gateway that you are logged into.

    Note: Blue Cedar does not recommend enabling console logging (It is disabled by default.) as these logs are basically duplicates of the logs sent to the "log" target.

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; 
}
BASH

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; 
  } 
}
BASH


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
BASH

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; 
}
BASH


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; 
}
BASH


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
BASH

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;
}
BASH