Using Syslog
  
Using Syslog
This topic provides a reference to the SteelConnect system logging (syslog) messages that report events of interest within the SteelConnect system.
This topic describes:
• Syslog overview
• Exporting syslog messages to a remote syslog server
• Remote and local syslog message priorities
• Remote syslog messages
• Remote log server Rsyslog version recommendations
Syslog overview
When an event occurs, SteelConnect generates a syslog message and places it in a syslog file directory in a local directory on the appliance and exports it to a remote system log server, if a remote server is configured. The remote syslog server receives a subset of the local logs that contains the most important and useful system logs gathered from all appliances within an organization. The log messages collected on the remote server capture the events most relevant for troubleshooting a network.
SteelConnect 2.12 includes many new log messages, and all log messages are now easier to understand. In addition, the logs now list interface names, IP addresses, and time stamps. All messages are stored in a central location.
By default, SteelConnect logs all syslog messages with a priority level of Info and above. The default Info level is a priority 6, so all messages with a priority of Notice, Warning, Error, Critical, Alert, and Emergency (priority levels 5 through 0, respectively) are included in the log. For details, see Remote and local syslog message priorities.
Local logging versus remote logging
SteelConnect provides local logging at the appliance level and remote logging for enterprises that require log exporting to a central server.
• Local logging - Collects every syslog message generated by all appliances in an organization, including those marked for export to a remote server. The local logs can be useful for detailed troubleshooting, but because they contain every log message, the vast amount of information logged can make it hard to pinpoint the most essential diagnostic information. To view the contents of a syslog file on a local appliance, enter the show log command from the CLI (supported on SteelHead SD appliances and the SteelConnect SDI-2030 and SDI-5030 gateways). For details, see Using the CLI on SteelHead SD appliances.
• Remote logging - Collects the most useful syslog messages from the entire log and stores a subset on a remote server. On the SteelHead SD appliances and the SteelConnect SDI-2030 and SDI-5030 gateways, these logs are collected from all VMs and exported to a remote syslog server by each appliance or gateway.
Exporting syslog messages to a remote syslog server
With remote logging, all syslogs from different appliances within an organization can be exported, aggregated, and stored in a single remote server located within the same enterprise network. Remote logging is configured for on-premise SteelConnect appliances sending logs to an on-premise syslog server to keep security, compliance, and audit requirements intact.
You can also export syslog messages to a local enterprise collector.
When an event occurs, SteelConnect generates a syslog message and places it in a syslog file in a directory on the local device. Messages that are flagged by SteelConnect for export are sent to any configured remote servers.
All logs are aggregated on the remote servers for viewing at a later time. Using third-party log analysis software (such as Splunk or Loggly) makes log management and reporting simpler. You can use the collected messages on the remote syslog servers to set up system alerts. In addition, log aggregation and storage provides a definitive archive.
SteelConnect does not support configuring syslog servers in a primary and backup configuration.
To send syslog data to a remote server
1. At the realm level, select the Logging tab.
2. Under Remote Logging, click On.
3. Click Add Remote Log Server.
4. Select the protocol used to transfer the log to the syslog server: TCP, UDP, or TLS (Transport Layer Security version 2.12). The default setting is UDP. You can use TCP for guaranteed log forwarding or UDP when speed is desirable and error correction isn’t necessary.
When you select TLS as the transport method, you must copy a certificate for the remote log server in the remote log server certificate field. TLS uses a handshake process to authenticate the server and appliance. After the handshake is complete, the server and appliance negotiate an encryption algorithm and cryptographic keys before exchanging data. Log messages are encrypted during their transfer to the remote server.
The TLS authentication process on the appliance uses the:
– appliance certificate generated by the Riverbed core service that is made available by default during manufacturing.
– appliance private key.
– certificate of CA that signed the server certificates.
The TLS authentication process on the remote server uses the:
– server certificate generated by any trusted authority.
– server private key.
– certificate of the Riverbed core service.
The appliance certificate area is read-only.
5. Click Enable.
6. Specify the remote syslog server’s IPv4 address or hostname. The remote server must be running the standard syslogd utility.
7. Specify the syslog server port number on which to send syslog messages: for example, 514 for UDP. Use the same port number on the firewall and the syslog server. The default setting is 514.
8. Specify a text string to prepend to messages sent by the log source. The string prefix is added to each syslog entry being forwarded. When you add a prefix to a syslog entry, you can then easily search for a specific log entry based on the prefix. The default prefix is REALM.
9. Select the minimum severity level for the log messages to control the amount of messages logged. By default, SteelConnect logs all syslog messages with a priority level of Info and above to the local appliance’s hard disk and to all configured remote syslog servers. The default Info level is a priority 6, so all messages with a priority of Notice, Warning, Error, Critical, Alert, and Emergency (priority levels 5 through 0, respectively) are included in the log. Only emergency-level messages will be logged when you select severity level 0.
Select a level from the drop-down list:
0 - Emergency - Critical alerts, errors, and security events; the system is unusable.
1 - Alert - Action must be taken immediately.
2 - Critical - Conditions that affect the functionality of the appliance or gateway.
3 - Error - Conditions that probably affect the functionality of the appliance or gateway.
4 - Warning - Conditions that could affect the functionality of the appliance or gateway, such as authentication failures.
5 - Notice - Normal but significant conditions, such as a configuration change.
6 - Info - Informational messages that provide general information about system operations. This is the default setting.
7 - Debug - Debugging messages that provide general information about system operations.
10. Click Submit.
SCM pushes the configuration to the SteelConnect appliances, and all appliances within an organization use this configuration to transport remote syslog messages to all configured remote syslog servers.
For details on the remote log server package versions and a package sample configuration, see Remote log server Rsyslog version recommendations.
For details on the syslog message format and a list of syslog messages, see Remote syslog messages.
Viewing the remote log server configuration
You can view the remote log server configuration for an organization. When logging is disabled at the organization level, SCM displays the realm level remote server and status.
To view a list of remote log servers
1. Choose Organization and select the organization.
2. Select the Logging tab.
Remote message format
Each log message is distinguished by the organization name, site name, appliance, and service. Syslog messages generated by SteelConnect use this format:
<priority> <version> <time-stamp> <hostname> <app-name> <process-id> [SD-ID org-name site-name prefix] <message>
Where:
• <priority> - A numerical reference to the facility and severity of the message. The priority value is a calculation of these two factors. For details, see RFC section 6.2.1. For severity levels, see Remote and local syslog message priorities.
• <version> - The value is 1. Denotes the version of syslog specification.
• <time-stamp> - The time when the message was generated in the ISO 8601 compatible standard time-stamp format. For example: yyyy-mm-ddThh:mm:ss+-ZONE. For details, see RFC section 6.2.3.
• <hostname> - The appliance that originally sent the syslog message. In SteelConnect 2.12 and later, this is the serial number of the appliance.
• <app-name> - The device or application that originated the message. The NILVALUE is returned when the syslog application can’t provide that information because the device is unable to provide that information either because of a local policy decision, or because the information is not available, or not applicable, on the device.
• <process-id> - The name or number of the process that issued the message.
• [contents of structured data] - Content within the square brackets ([ ]) includes:
– SD-ID (structured data ID) - SteelConnect@17163. The number 17163 refers to the IANA private enterprise value assigned to Riverbed.
– SD-PARAM (structured data parameters) - org-name, site-name, prefix.
– <message> - Provides information about the event. For details, see Remote syslog messages.
Empty fields are indicated with a dash (-).
When a remote syslog server is configured, SteelConnect exports a subset of the syslog messages. On SteelHead SD appliances and the SDI-2030 gateway, a <C> appearing at the end of a local message indicates that the message will be captured for export to the remote server. The <C> doesn’t appear at the end of the message on the remote server.
Remote and local syslog message priorities
Message priorities control how many syslog messages are logged. The message priority level is configured by the realm administrator. Deciding the priority level is a tradeoff between using up the disk space to store the messages too quickly versus not having enough information in your logs. All messages that fall into the configured priority level are logged, along with all levels above that level. For example, Debug has the lowest severity, so choosing that level will log all messages in all severity levels. Selecting the highest level, Emergency, will log the fewest messages.
All syslog messages fall into one of these severity levels:
0 - Emergency - Critical alerts, errors, and security events; the system is unusable.
1 - Alert - Action must be taken immediately.
2 - Critical - Conditions that affect the functionality of the appliance or gateway.
3 - Error - Conditions that probably affect the functionality of the appliance or gateway.
4 - Warning - Conditions that could affect the functionality of the appliance or gateway, such as authentication failures.
5 - Notice - Normal but significant conditions, such as a configuration change.
6 - Info - Informational messages that provide general information about system operations. This is the default severity level.
7 - Debug - Debugging messages that provide general information about system operations.
Local system log storage capacity
Every VM within a SteelHead SD appliance and SDI-2030 gateway, for example, the Control VM (CVM), Routing VM (RVM), and Service VM (SVM), can use up to 10 percent of the virtual machine’s disk space for syslogs by default. After the available log file disk space is used, the oldest logs are automatically rotated to create room for newer logs.
Each SDI gateway model provides up to 10 MB of available storage for syslogs.
By default, SteelConnect logs all syslog messages with a priority level of Info and above to the local appliance’s hard disk. The default Info level is a priority 6, so all messages with a priority of Notice, Warning, Error, Critical, Alert, and Emergency (priority levels 5 through 0, respectively) are included in the log. For details, see Remote and local syslog message priorities.
The log files are placed in chronological order on the local SDI gateway.
Remote syslog messages
Syslog messages report on these events:
Appliance-specific messages
• Overall system health statistics
• Tunnel keying on SDI-2030 gateways, SDI-5030 gateways, and SteelHead SD appliances.
• Tunnel events on SDI-2030 gateways, SDI-5030 gateways, and SteelHead SD appliances.
• Zone configuration events
• DHCP configuration events
• SCM communication events
• Interface status events
• Local and remote backup uplink events
Routing virtual machine (RVM)-specific messages
• Routing table Forwarding Information Base (FIB) events
• Dynamic routing session events (BGP and OSPF)
• High availability appliance role events
• Subnet reachability events
IKE tunnels
• Classic VPN, Zscaler, and Cloudi-Fi tunnel events (all IKEv2 tunnels)
The following tables list the syslog messages and the event that triggers the message. If you see a syslog message that doesn’t appear in a table, send the message and SteelConnect version to techpubs@riverbed.com.
Appliance-specific syslog messages
Message on SDI gateway models 130, 330, 1030 and 5030
Message on SteelHead SD appliances and the SDI-2030 gateway
Log level/priority
Description
System Health stats update: Peak Mem Usage: 16 %; Median Mem Usage: 0 %; Peak CPU Usage: 3 %; Median CPU Usage: 0 %; Ports Up: 3; Ports down: 8; Aggregated rx bytes: 7184956; Aggregated tx bytes: 3278499; Tunnels established: 4; IPv4 Uplinks Up: 2; IPv4 Uplinks INUSE: 2 IPv6 Uplinks Up: 2; IPv6 Uplinks INUSE: 0
System Health stats update: Peak Mem Usage: 16 %; Median Mem Usage: 0 %; Peak CPU Usage: 3 %; Median CPU Usage: 0 %; Ports Up: 3; Ports down: 8; Aggregated rx bytes: 7184956; Aggregated tx bytes: 3278499; Tunnels established: 4; IPv4 Uplinks Up: 2; IPv4 Uplinks INUSE: 2 IPv6 Uplinks Up: 2; IPv6 Uplinks INUSE: 0
Info/Low
This periodic summary log is sent out every 30 minutes to indicate the total throughput sent through the gateway or appliance between the last log push for this event. The log indicates how much data flowed through the gateway or appliance in the last 30 minutes. The log includes this information:
• CPU/memory utilization.
• Number of tunnels that are up or down.
• Number of uplinks that are in use or down.
• Number of ports that are up or down.
• Aggregate throughput since the last update.
The summary doesn’t include switch throughput.
SCM event triggered: Connectivity to SCM went down
Nov 18 17:12:55 xnae9b0bbeb6c666 /usr/bin/ztpd[27304]: [INFO] ztpd: SCM event triggered: Connectivity to SCM went down
Info
An SCM connectivity change occurred. A gateway or appliance went down.
SCM event triggered: Connectivity to SCM went up
Nov 18 17:12:55 xnae9b0bbeb6c666 /usr/bin/ztpd[27304]: [INFO] ztpd: SCM event triggered: Connectivity to SCM went up
Info
An SCM connectivity change occurred. A gateway or appliance that was down is now up.
Device event triggered: Device did not restart cleanly. Possible loss of power. Stop service was not executed
Not supported
Info
A device power change brown out has occurred.
Device event triggered: CPU utilization severity CRITICAL:Utilization is equal or went above xx%: Current percentage: xx%
Nov 18 07:14:24 steelos-cvm /usr/bin/nx-eventD[2056]: [INFO] nx-eventD: Device event triggered: CPU utilization severity MODERATE: Utilization is equal or went above xx%: Current utilization: xx%
Info
0-79%
Warn
80-99%
Critical
100%
The CPU utilization is above the normal threshold.
Moderate = 60%
High= 80%
Critical =90%
Fatal= 100%
Device event triggered: memory utilization severity CRITICAL:Utilization is equal or went above xx%: Current percentage: xx%
Nov 18 07:14:24 steelos-cvm /usr/bin/nx-eventD[2056]: [INFO] nx-eventD: Device event triggered: Memory utilization severity MODERATE: Utilization is equal or went above xx%: Current percentage: xx%
Info
0-79%
Warn
80-99%
Critical
100%
The memory utilization is above the normal threshold.
Moderate - 60%
High - 80%
Critical - 90%
Fatal - 100%
SCM event triggered: Received action FIRMWARE_UPGRADE from SCM
Nov 18 17:45:53 xnae9b0bbeb6c666 /usr/bin/ztpd[27304]: [INFO] ztpd: SCM event triggered: Received action FIRMWARE_UPGRADE from SCM
Info
The appliance received a firmware upgrade request from SCM.
SCM event triggered: Action received from SCM FIRMWARE_UPGRADE failed with error
Nov 18 18:09:34 xnae9b0bbeb6c666 /usr/bin/setupd[27314]: [INFO] setupd: SCM event triggered: Action received from SCM FIRMWARE_UPGRADE failed with error
Info
The firmware upgrade request has failed.
SCM event triggered: Received action FIRMWARE_UPGRADE finished successfully
Nov 18 17:45:53 xnae9b0bbeb6c666 /usr/bin/ztpd[27304]: [INFO] ztpd: SCM event triggered: Received action FIRMWARE_UPGRADE finished successfully
Info
The firmware upgrade was successful.
SCM event triggered: Received action FIRMWARE_DOWNLOAD from SCM
Nov 18 17:45:53 xnae9b0bbeb6c666 /usr/bin/ztpd[27304]: [INFO] ztpd: SCM event triggered: Received action FIRMWARE_DOWNLOAD from SCM
Info
A firmware download event has been triggered.
SCM event triggered: Action received from SCM FIRMWARE_DOWNLOAD failed with error
Nov 18 18:09:34 xnae9b0bbeb6c666 /usr/bin/setupd[27314]: [INFO] setupd: SCM event triggered: Action received from SCM FIRMWARE_DOWNLOAD failed with error
Info
The firmware download has failed.
SCM event triggered: Received action FIRMWARE_DOWNLOAD finished successfully
Nov 18 17:45:53 xnae9b0bbeb6c666 /usr/bin/ztpd[27304]: [INFO] ztpd: SCM event triggered: Received action FIRMWARE_DOWNLOAD finished successfully
Info
The firmware download was successful.
SCM event triggered: Received action FIRMWARE_SWITCH from SCM
Nov 18 17:45:53 xnae9b0bbeb6c666 /usr/bin/ztpd[27304]: [INFO] ztpd: SCM event triggered: Received action FIRMWARE_SWITCH from SCM
Info
A reboot to switch to the updated firmware has been triggered.
SCM event triggered: Action received from SCM FIRMWARE_SWITCH failed with error
Nov 18 18:09:34 xnae9b0bbeb6c666 /usr/bin/setupd[27314]: [INFO] setupd: SCM event triggered: Action received from SCM FIRMWARE_SWITCH failed with error
Info
The reboot to switch the firmware to the upgraded version has failed.
SCM event triggered: Received action FIRMWARE_SWITCH finished successfully
Nov 18 17:45:53 xnae9b0bbeb6c666 /usr/bin/ztpd[27304]: [INFO] ztpd: SCM event triggered: Received action FIRMWARE_SWITCH finished successfully
Info
The firmware switch to the upgraded version was successful.
SCM event triggered: Received action from SCM CONFIG_UPDATE
Nov 18 17:45:53 xnae9b0bbeb6c666 /usr/bin/ztpd[27304]: [INFO] ztpd: SCM event triggered: Received action from SCM CONFIG_UPDATE
Info
A configuration update has been triggered.
SCM event triggered: Action received from SCM CONFIG_UPDATE failed with error
Nov 18 18:09:34 xnae9b0bbeb6c666 /usr/bin/setupd[27314]: [INFO] setupd: SCM event triggered: Action received from SCM CONFIG_UPDATE failed with error
Info
The configuration update request has failed.
SCM event triggered: Received action CONFIG_UPDATE finished successfully
Nov 18 17:45:53 xnae9b0bbeb6c666 /usr/bin/ztpd[27304]: [INFO] ztpd: SCM event triggered: Received action CONFIG_UPDATE finished successfully
Info
The configuration update was successful.
SCM event triggered: Received action REBOOT
Nov 18 17:45:53 xnae9b0bbeb6c666 /usr/bin/ztpd[27304]: [INFO] ztpd: SCM event triggered: Received action from SCM REBOOT
Info
A request to reboot an appliance has been triggered.
SCM event triggered: Received action from SCM REBOOT failed with error
Nov 18 18:09:34 xnae9b0bbeb6c666 /usr/bin/setupd[27314]: [INFO] setupd: SCM event triggered: Received action from SCM REBOOT failed with error
Info
The appliance reboot request has failed.
SCM event triggered: Received action REBOOT finished successfully
Nov 18 17:45:53 xnae9b0bbeb6c666 /usr/bin/ztpd[27304]: [INFO] ztpd: SCM event triggered: Received action REBOOT finished successfully
Info
The appliance reboot was successful.
SCM event triggered: Received action from SCM FACTORY_RESET
Nov 18 17:45:53 xnae9b0bbeb6c666 /usr/bin/ztpd[27304]: [INFO] ztpd: SCM event triggered: Received action from SCM FACTORY_RESET
Info
A request to reset an appliance to its original factory configuration has been triggered.
SCM event triggered: Received action from SCM FACTORY_RESET failed with error
Nov 18 18:09:34 xnae9b0bbeb6c666 /usr/bin/setupd[27314]: [INFO] setupd: SCM event triggered: Received action from SCM FACTORY_RESET failed with error
Info
The factory reset request has failed.
SCM event triggered: Recived action FACTORY_RESET finished successfully
Nov 18 17:45:53 xnae9b0bbeb6c666 /usr/bin/ztpd[27304]: [INFO] ztpd: SCM event triggered: Received action FACTORY_RESET finished successfully
Info
The appliance was successfully reset to its original factory configuration.
SCM event triggered: Received action from SCM INVENTORY_UPDATE
Nov 18 17:45:53 xnae9b0bbeb6c666 /usr/bin/ztpd[27304]: [INFO] ztpd: SCM event triggered: Received action from SCM INVENTORY_UPDATE
Info
A request to update the inventory has been triggered.
SCM event triggered: Received action from SCM INVENTORY_UPDATE failed with error
Nov 18 18:09:34 xnae9b0bbeb6c666 /usr/bin/setupd[27314]: [INFO] setupd: SCM event triggered: Received action from SCM INVENTORY_UPDATE failed with error
Info
The inventory update has failed.
SCM event triggered: Received action INVENTORY_UPDATE finished successfully
Nov 18 17:45:53 xnae9b0bbeb6c666 /usr/bin/ztpd[27304]: [INFO] ztpd: SCM event triggered: Received action INVENTORY_UPDATE finished successfully
Info
The inventory update was successful.
Uplink configuration changed: Created: Uplink name: Uplink-alex <Port: WAN1>
Uplink configuration changed: Deleted: Uplink name: Uplink-alex <Port: WAN1>
Sep 20 17:08:52 ns-1.5-svm-2 scm_service[11000]: [SCM_Service.INFO]: Uplink configuration changed: Uplink-wan1 - ip_v4: 10.155.2.200 mtu: 1499
Sep 20 17:09:28 ns-1.5-svm-2 scm_service[11000]: [SCM_Service.INFO]: Uplink configuration changed: Deleted: Uplink-wan1
Sep 20 17:10:34 ns-1.5-svm-2 scm_service[11000]: [SCM_Service.INFO]: Uplink configuration changed: Created: Uplink name: Uplink_wan1, Port: wan0_1
Sep 20 17:11:07 ns-1.5-svm-2 scm_service[11000]: [SCM_Service.INFO]: Uplink configuration changed: Uplink-wan1 - qos: {u'inbound': {u'enabled': 0, u'bandwidth_bps': 100000000}, u'outbound': {u'enabled': 1, u'bandwidth_bps': 100000000}}
INFO
An uplink’s IPv4 address and MTU has changed.
An uplink has been created.
An uplink has been deleted.
An uplink’s QoS configuration has changed. The message describes the exact change.
Not supported
Nov 01 10:38:25 ns-1.5-svm-2 /usr/lib/python2.7/site-packages/control_manager/control_manager.pyc[7268]: [INFO] SecureOverlay: Adding cached key for tunnel between appliance source XN00C8E439B0831D and destination appliance XN0EE7BCED7717D9
Nov 01 10:38:25 ns-1.5-svm-2 /usr/lib/python2.7/site-packages/control_manager/control_manager.pyc[7268]: [INFO] SecureOverlay: Replacing key for tunnel between appliance source XN00C8E439B0831D and destination appliance XN0EE7BCED7717D9
Nov 01 10:38:25 ns-1.5-svm-2 /usr/lib/python2.7/site-packages/control_manager/control_manager.pyc[7268]: [INFO] SecureOverlay: Activating encryption key for tunnel between appliance source XN00C8E439B0831D and destination appliance XN0EE7BCED7717D9
Nov 01 10:38:25 ns-1.5-svm-2 /usr/lib/python2.7/site-packages/control_manager/control_manager.pyc[7268]: [INFO] SecureOverlay: Activating decryption key for tunnel between appliance source XN00C8E439B0831D and destination appliance XN0EE7BCED7717D9
Info
VPN keying events:
• New key received and cached for the tunnel between an appliance and source.
• Key replaced for the tunnel between the appliance and the source.
• Encryption key activated for the tunnel between the appliance source and the destination appliance.
• Decryption key activated for the tunnel between the appliance source and the destination appliance.
SCM event triggered: root: Secondary partition:<version_name>
root: Primary partition:<2.12.0.197>
SCM event triggered: Primary Partition: <version_name>
Secondary Partition:
< version_name>
Notice
Indicates the primary and secondary partition version before an upgrade.
SCM event triggered: root: Secondary partition:<version_name>
root: Primary partition:<version_name>
SCM event triggered: Primary Partition: <version_name>
Secondary Partition:<version_name>
Notice
Indicates the primary and secondary partition version after an upgrade.
SCM event triggered: Zone config changed, operation ADD, zone name: <zone name>
SCM event triggered: Zone config changed, operation ADD, zone name: <zone name>
Info
A zone has been added. The message includes the new zone name.
SCM event triggered: Zone config changed, operation DELETE, zone name: <zone name>
SCM event triggered: Zone config changed, operation DELETE, zone name: <zone name>
Info
A zone has been deleted. The message includes the deleted zone name.
SCM event triggered: Zone config changed, operation UPDATE, zone name: 1000 diff: subnet: 172.16.0.0/24
Zone config changed, operation UPDATE, zone name: 1000 diff: DHCP: 172.16.0.0/24 Zone config changed, operation UPDATE, zone name: 1004 diff: subnet: 172.16.4.0/24
Zone config changed, operation UPDATE, zone name: 1004 diff: DHCP: 172.16.4.0/24
Zone config changed, operation UPDATE, zone name: 1005 diff: subnet: 172.16.5.0/24
SCM event triggered: Zone config changed, operation UPDATE, zone name: 1000 diff: subnet: 172.16.0.0/24
Zone config changed, operation UPDATE, zone name: 1000 diff: DHCP: 172.16.0.0/24 Zone config changed, operation UPDATE, zone name: 1004 diff: subnet:172.16.4.0/24
Zone config changed, operation UPDATE, zone name: 1004 diff: DHCP: 172.16.4.0/24
Zone config changed, operation UPDATE, zone name: 1005 diff: subnet: 172.16.5.0/24
Zone config changed, operation UPDATE, zone name: 1005 diff: DHCP: 172.16.5.0/24
Info
A change has been made to the IP or DHCP zone configuration.
Interface status changed: Interface LAN1 went Up
Interface status changed: Interface LAN1 went Down
Nov 18 04:24:48 steelos-cvm /usr/bin/nx-eventD[2056]: [INFO] nx-eventD: Interface status changed: Interface PRIMARY went Down
Nov 18 04:24:48 steelos-cvm /usr/bin/nx-eventD[2056]: [INFO] nx-eventD: Interface status changed: Interface WAN0_0 went Up
Nov 18 04:24:48 steelos-cvm /usr/bin/nx-eventD[2056]: [INFO] nx-eventD: Interface status changed: Interface WAN0_1 went Down
Nov 18 04:24:48 steelos-cvm /usr/bin/nx-eventD[2056]: [INFO] nx-eventD: Interface status changed: Interface AUX went Down
Nov 18 04:24:48 steelos-cvm /usr/bin/nx-eventD[2056]: [INFO] nx-eventD: Interface status changed: Interface LAN0_1 went Down
Nov 18 04:24:48 steelos-cvm /usr/bin/nx-eventD[2056]: [INFO] nx-eventD: Interface status changed: Interface LAN0_0 went Down
Info
An interface status has changed. The appliance ID and interface are included in the message.
Routing virtual machine (RVM) remote syslog messages
Message on SDI Gateway Models SDI-2030, SDI-5030, and SteelHead SD
Log Level/Priority
Description
DHCP Interface add <interface name> ip <interface ip>
Info
A DHCP interface has been added.
DHCP Interface delete <interface name> ip <interface ip>
Info
A DHCP interface has been deleted.
Adding FIB entry Prefix <prefix> Gateway <gateway> and Dst RVM port <port> community <community>
Debug
A Forwarding Information Base (FIB) prefix has been added to the FIB table.
Deleting FIB entry Prefix <prefix>
Debug
A Forwarding Information Base (FIB) prefix has been deleted from the FIB table.
HA Event Received HA Event <role1> → <role2>
Info
A high-availability (HA) event for an appliance role change from master to backup or from backup to master has been received.
Reachable Subnet Event <event> for subnet <subnet> received with preference <preference> and distance <distance>
Debug
An overlay route event has been received.
BGP state change <peer-ip>-Outgoing State Change: <state1> → <state2>
Info
A BGP session state has changed.
The BGP states are Idle, Connect, OpenSent, Active, OpenConfirm, or Established.
OSPF state change
NFSM[<port>:<port-ip>-<router_id>]: Status change <state1> → <state2>
Info
An OSPF session state has changed.
The OSPF states are Down, Init, 2-way, ExStart, Exchange, Loading, Full, or Backup.
VRRP state change
VRRP enabled on interface <interface name> changed from <state1> → <state2>
Info
A VRRP state has changed.
The VRRP states are Init, Master, or Backup.
VRRP session enabled on interface <interface name>
Info
A VRRP session has been enabled on an interface.
Message on SDI gateway models 130, 330, 1030, and 5030
Message on SteelHead SD appliances and the SDI-2030 gateway
 
Log Level/Priority
Description
User Action
Remote log server Rsyslog version recommendations
SteelConnect 2.12 uses the system utility Rsyslog to forward log messages. This section lists the Rsyslog version numbers that SteelConnect uses. We strongly recommend that you install these same versions or later versions on the remote server to avoid compatibility issues:
• rsyslog-8.24.0-12.el7.x86_64
• rsyslog-relp-8.24.0-12.el7.x86_64
• rsyslog-gnutls-8.24.0-12.el7.x86_64
• gnutls-3.3.26-9.el7.x86_64
Sample remote server configuration
The following sample server configuration uses Rsyslogd as the log collector and UDP, TCP, and TLS as the transport methods.
# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514
 
# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 1024
 
$ActionFileDefaultTemplate RSYSLOG_SyslogProtocol23Format
 
#### RULES ####
 
# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.* /dev/console
 
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none /var/log/messages
 
# The authpriv file has restricted access.
#authpriv.* /var/log/secure
 
# Log all the mail messages in one place.
#mail.* -/var/log/maillog
 
 
# Log cron stuff
#cron.* /var/log/cron
 
# Everybody gets emergency messages
#*.emerg :omusrmsg:*
 
# Save news errors of level crit and higher in a special file.
#uucp,news.crit /var/log/spooler
 
# Save boot messages also to boot.log
#local7.* /var/log/boot.log
 
#### TLS ##
module(load="imrelp" ruleset="relp")
input(type="imrelp" port="2048" tls="on"
tls.caCert="/etc/pki/rsyslog/ca_core.pem"
tls.myCert="/etc/pki/rsyslog/rslserver-cert.pem"
tls.myPrivKey="/etc/pki/rsyslog/rslserver-key.pem"
TLS.AuthMode="name"
tls.permittedpeer=["*"]
)
ruleset(name="relp") {
action(type="omfile" file="/var/log/messages_tls")
}