Log Messages for SRX Series Chassis Clusters

You can obtain information about the sessions and packet flows active on your device, including detailed information about specific sessions. (The SRX Series device also displays information about failed sessions.) You can display this information to observe activity and for debugging purposes.

For example, use the show security flow session command to:

• Display a list of incoming and outgoing IP flows, including services.

• Show the security attributes associated with a flow, for example, the policies that apply to traffic belonging to that flow.

• Display the session timeout value, when the session became active, how long it has been active, and if there is active traffic on the session.

For detailed information about this command, see the Junos OS CLI Reference.

Session information can also be logged if a related policy configuration includes the logging option. Session logging infrastructure logs the session log messages when a session is created, closed, denied, or rejected. In the SRX3000 and SRX5000 lines, the log messages are streamed directly to an external syslog server/repository, bypassing the Routing Engine. The SRX Series devices support both traditional and structured syslog. The SRX3000 and SRX5000 lines support 1000 log messages per second, and the management station must be equipped to handle this volume. See the Junos OS Security Configuration Guide for configuration examples and details about these logs. The logs are available through the management interface of both the primary and secondary nodes. Ensure that the external server receiving these log messages is reachable by both nodes.

The high-end SRX Series devices have a distributed processing architecture that processes traffic as well as generates log messages. In the SRX Series devices, the firewall processes the traffic sessions on each of the SPUs in the chassis. After each session is created, it is processed by the same SPU in the chassis, which is also the SPU that generates the log message.

The standard method of generating log messages is to have each SPU generate the message as a UDP syslog message and send it directly out the data plane to the syslog server. The SRX Series devices can log extremely high rates of traffic. They can log up to 750 MB per second of log messages, which surpasses the limits of the control plane. Therefore, we do not recommended logging messages to the control plane, except under certain circumstances.

For SRX Series branch devices running Junos OS Release 9.6 and later and high-end SRX Series devices running Junos OS Release 10.0 and later, the devices can log messages to the control plane at a limited maximum rate (1000 log messages per second) rather than logging to the data plane. If the log messages are sent through the data plane using syslog, a syslog collector—such as the Juniper Security Threat Response Manager (STRM)—must be used to collect the logs for viewing, reporting, and alerting. In SRX Series branch devices running Junos OS Release 9.6 and later and high-end SRX Series devices running Junos OS Release 10.0 and later, the devices can only send log messages to the data plane or the control plane, but not to both at the same time.

If the management station cannot receive log messages from the data plane, then configure it to send messages through the management connection. If you log to the control plane, the SRX Series devices can also send these syslog messages out the fxp0 interface. If event logging is configured, all log messages from the data plane go to the control plane.

1. Configure event logging.

   user@host# set security log mode event

2. Rate-limit the event log messages.

   It might be necessary to rate-limit the event log messages from the data plane to the control plane due to limited resources on the control plane to process high volumes of log messages. This is especially applicable if the control plane is busy processing dynamic routing protocols such as BGP or large-scale routing implementations. The following command rate-limits the log messages so that they do not overwhelm the control plane. Log messages that are rate-limited are discarded. A best practice for high-end SRX Series devices is to log no more than 1000 log messages per second to the control plane.

   user@host# set security log mode event event-rate logs per second

The SRX Series branch device traffic log messages can be sent through the data plane security logs in stream mode. Note that this is possible only using stream mode. The following is a sample configuration and log output.

Configuration

Sample Log Message Output

In this case, the SRX Series device traffic log messages are sent to an external syslog server through the dataplane. This ensures that the Routing Engine is not a bottleneck for logging. It also ensures that the Routing Engine does not get impacted during excessive logging. In addition to traffic log messages, the control plane and the log messages sent to the Routing Engine are written to a file in flash memory. The following is a sample configuration to enable this type of logging.

Configuration

Syslog (self logs)—This configuration can be customized as per required self logging.

Traffic logs ( using dataplane)

In this case both the traffic log messages and log messages sent to the Routing Engine are sent to a syslog server. The following is a sample configuration to enable this type of logging.

Configuration

Syslog (syslog server)

Traffic logs

The SRX Series device control plane is responsible for overall control of the SRX Series platform, along with running a number of software processes to perform tasks such as routing protocol operations, routing table calculations, managing administrators, managing SNMP, authentication, and many other mission-critical functions. There are a wide range of log messages that are generated on the control plane, and the control plane offers granular support for defining what log messages should be written to both files as well as sent to syslog servers. This topic provides an overview of how to configure various syslog options on the control plane. Only sending log messages through syslog services is covered in this section.

You can configure the SRX Series device to send only traffic logs to the syslog server using the control plane.

In this configuration:

• No security logs are configured.

• No control plane logs are received.

Use the match statement regular expression to send traffic log messages only. These log messages are sent directly to the syslog server without writing them to flash memory. This configuration does not send log messages normally sent to the Routing Engine to the syslog server. However, it is possible to create a separate file and write control plane log messages to a file on the Routing Engine as shown.

Configuration

Sample log messages:

The following configuration sends both traffic and control log messages to the syslog server, but might overwhelm the syslog server and cause cluster instability. We do not recommend using this configuration.

Configuration

Security log event mode is the default mode on SRX Series branch devices, and it is not advisable for these devices. We recommend changing the default behavior.

You might want to deploy fault management and performance management applications and systems such as Juniper Networks Security Threat Response Manager (STRM). STRM collects log messages through the management network and is connected through the fxp0 interface. The fault management and performance management applications manage the SRX Series device through the fxp0 interface, but the SRX Series device also needs to send the data plane log messages to STRM on the same network. For instance, if the rate of log messages is going to be greater than 1000 log messages per second, then logging to the control plane is not supported. The issue is that two interfaces in the same virtual router cannot be in the same subnet, and the fxp0 interface cannot be moved to any virtual router other than inet.0.

To work around these issues, place a data plane interface in a virtual router other than the default virtual router inet.0, and place a route in the inet.0 routing table to route traffic to STRM through that virtual router. The following configuration example shows how to do this.

In this example:

• fxp0 has an IP address of 172.19.200.164/24.

• Application A (AppA) has an IP address of 172.19.200.175.

• STRM has an IP address of 172.19.200.176.

• The ge-0/0/7 interface is a data plane interface, with an IP address of 172.19.200.177/24 (which is in the same subnet as the fxp0 interface).

To configure this example, include the following statements: