Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Flow-Based Sessions

 

The Junos OS caches the session information that is triggered by the first packet of the flow. The cached session is used by subsequent packets of that same flow and the reverse flow of that session using the flow module, which is integrated into the forwarding path.

Understanding Session Characteristics for SRX Series Services Gateways

Sessions are created, based on routing and other classification information, to store information and allocate resources for a flow. Sessions have characteristics, some of which you can change, such as when they are terminated. For example, you might want to ensure that a session table is never entirely full to protect against an attacker’s attempt to flood the table and thereby prevent legitimate users from starting sessions.

Depending on the protocol and service, a session is programmed with a timeout value. For example, the default timeout for TCP is 1800 seconds. The default timeout for UDP is 60 seconds. When a session is terminated, it is marked as invalid, and its timeout is reduced from 20 to 4 seconds.

If no traffic uses the session before the service timeout, the session is aged out and freed to a common resource pool for reuse. You can affect the life of a session in the following ways:

  • You can specify circumstances for terminating sessions by using any of the following methods:

    • Age out sessions based on how full the session table is

    • Set an explicit timeout for aging out TCP sessions

    • Configure a TCP session to be invalidated when it receives a TCP RST (reset) message

    • Configure the fin-invalidate-session statement to terminate sessions when either session endpoint sends a FIN(ish) message to its peer.

      When the peer endpoint receives the packet with the FIN flag set, it sends an ACK(nowlege) message. Typically, tearing down a session using this method involves transmission of a pair of FIN-ACK messages from each session.

  • You can configure sessions to accommodate other systems as follows:

    • Disable TCP packet security checks

    • Change the maximum segment size

Understanding Aggressive Session Aging

The session table is a limited resource for SRX Series devices. If the session table is full, any new sessions will be rejected by the device.

The aggressive session-aging mechanism accelerates the session timeout process when the number of sessions in the session table exceeds the specified high-watermark threshold. This mechanism minimizes the likelihood that the SRX Series devices will reject new sessions when the session table becomes full.

Configure the following parameters to perform aggressive session aging:

  • high-watermark–The device performs aggressive session aging when the number of sessions in the session table exceeds the high-watermark threshold.

  • low-watermark–The device exits aggressive session aging and returns to normal when the number of sessions in the session table dips below the low-watermark threshold.

  • early-ageout –During aggressive session aging, the sessions with an age-out time lower than the early-ageout threshold are marked as invalid.

On SRX1400, SRX3400, SRX3600, SRX5600, and SRX5800 devices, the SPU checks the session table, locates the sessions for which the timeout value is lower than the early-ageout time value, and then marks them as invalid. (Platform support depends on the Junos OS release in your installation.)

Example: Controlling Session Termination for SRX Series Services Gateways

This example shows how to terminate sessions for SRX Series devices based on aging out after a certain period of time, or when the number of sessions in the session table is full or reaches a specified percentage. You specify a timeout value or the number of sessions in the session table.

Requirements

Before you begin, understand the circumstances for terminating sessions.

Overview

You can control session termination in certain situations—for example, after receiving a TCP FIN Close or receiving an RST message, when encountering ICMP errors for UDP, and when no matching traffic is received before the service timeout. When sessions are terminated, their resources are freed up for use by other sessions.

In this example, you configure the following circumstances to terminate the session:

  • A timeout value of 20 seconds.

    Note

    The minimum value you can configure for TCP session initialization is 4 seconds. The default value is 20 seconds; if required you can set the TCP session initialization value to less than 20 seconds.

  • An explicit timeout value of 280 seconds, which changes the TCP session timeout during the three-way handshake.

    The command sets the initial TCP session timeout to 280 in the session table during the TCP three-way handshake. The timer is initiated when the first SYN packet is received, and reset with each packet during the three-way handshake. Once the three-way handshake is completed, the session timeout is reset to the timeout defined by the specific application. If the timer expires before the three-way handshake is complete, the session is removed from the session table.

  • Any session that receives a TCP RST (reset) message is invalidated.

Configuration

Step-by-Step Procedure

To control session termination for SRX Series devices:

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see.... Using the CLI Editor in Configuration Mode in theCLI User Guide.

To control session termination for SRX Series devices:

  1. Specify an age-out value for the session.

  2. Configure an aging out value.
  3. Invalidate any session that receives a TCP RST message.
  4. If you are done configuring the device, commit the configuration.

Verification

To verify the configuration is working properly, enter the show security flow command.

Clearing Sessions for SRX Series Services Gateways

You can use the clear command to terminate sessions. You can clear all sessions, including sessions of a particular application type, sessions that use a specific destination port, sessions that use a specific interface or port, sessions that use a certain IP protocol, sessions that match a source prefix, and resource manager sessions.

Terminating Sessions for SRX Series Services Gateways

You can use the following command to terminate all sessions except tunnel and resource manager sessions. The command output shows the number of sessions cleared. Be aware that this command terminates the management session through which the clear command is issued.

Terminating a Specific Session for SRX Series Services Gateways

You can use the following command to terminate the session whose session ID you specify.

Using Filters to Specify the Sessions to Be Terminated for SRX Series Services Gateways

You can terminate one or more sessions based on the filter parameter you specify for the clear command. The following example uses the protocol as a filter.

Configuring the Timeout Value for Multicast Flow Sessions

You can configure the timeout value for multicast flow sessions by configuring a custom application and associating the application with a policy.

Multicast flow sessions have one template session and one or more leaf sessions. Because these sessions are linked together, they can have only one timeout value. The timeout value for multicast flow sessions is determined by considering the timeout values configured in the leaf session policies and the IP protocol timeout values. The highest of these timeout values is selected as the multicast flow session timeout.

If no leaf session timeout values are configured, the IP protocol timeout value is automatically used as the timeout value for the mulicast flow session. The IP protocol timeout is the default and is not configurable.

Configuring leaf session timeouts can be especially helpful for multicast streams that have a longer packet interval than the default IP protocol timeout. For example, multicast streams with a packet interval of more than 60 seconds would experience premature aging-out of flow sessions and packet drops with the UDP timeout value, which is always 60 seconds. For such streams, you can configure a higher leaf session timeout value and prevent packet drop.

To set the leaf session timeout value, configure a custom application and associate the application with a policy:

  1. Create a custom application, specify its properties, and specify bypassing the application type.
  2. Set the timeout value for the application protocol.
  3. Create a policy.
  4. Associate the custom application (with the configured timeout) to the policy.
  5. If you are done configuring the device, commit the configuration.
  6. To verify the updated session timeout value, enter the show security flow session command.
    user@host> show security flow session destination-prefix 203.0.113.0

    In this output, the session ID 2363 section displays a template session. A timeout value of 498 indicates that the template session timeout value is ticking down from the configured value of 500 seconds.

    The session ID 2364 section displays a leaf session. The timeout value of -1 essentially indicates that the session will not age out unless the template session ages out.

    In this example, the configured leaf session timeout value of 500 seconds is the highest timeout value and is accepted as the template session timeout value for the multicast flow session.