Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Packet-Based Forwarding

 

An SRX device operate in two different modes: packet mode and flow mode. In flow mode, SRX processes all traffic by analyzing the state or session of traffic. This is also called stateful processing of traffic. In packet mode, SRX processes the traffic on a per-packet basis. This is also known as stateless processing of traffic.

Understanding Packet-Based Processing

Packets that enter and exit a Juniper Networks device running Junos OS can undergo packet-based processing. Packet-based, or stateless, packet processing treats packets discretely. Each packet is assessed individually for treatment. Stateless packet-based forwarding is performed on a packet-by-packet basis without regard to flow or state information. Each packet is assessed individually for treatment.

Figure 1 shows the traffic flow for packet-based forwarding.

Figure 1: Traffic Flow for Packet-Based Forwarding
Traffic Flow for Packet-Based
Forwarding

As packets enter the device, classifiers, filters and policers are applied to it. Next, the egress interface for the packet is determined through a route lookup. Once the egress interface for the packet is found, filters are applied and the packet is sent to the egress interface where it is queued and scheduled for transmission.

Packet-based forwarding does not require any information about either previous or subsequent packets that belong to a given connection, and any decision to allow or deny traffic is packet specific. This architecture has the benefit of massive scaling because it forwards packets without keeping track of individual flows or state.

Starting with Junos OS Release 15.1X49-D100, for the SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX550M, and SRX650, the maximum capture size for packet captures is expanded to 1520 bytes to allow for captures of 1500 bytes of data and the 12-byte Juniper Ethernet header."

Understanding Selective Stateless Packet-Based Services

Selective stateless packet-based services allow you to use both flow-based and packet-based forwarding simultaneously on a system. You can selectively direct traffic that requires packet-based, stateless forwarding to avoid stateful flow-based forwarding by using stateless firewall filters, also known as access control lists (ACLs). The traffic not so directed follows the default flow-based forwarding path. Bypassing flow-based forwarding can be useful for traffic for which you explicitly want to avoid flow session-scaling constraints.

By default, Juniper Networks Security devices running Junos OS use flow-based forwarding. Selective stateless packet-based services allows you to configure the device to provide only packet-based processing for selected traffic based on input filter terms. Other traffic is processed for flow-based forwarding. Bypassing flow-based forwarding is useful for deployments where you want to avoid session-scaling constraints and session creation and maintenance costs.

When you configure the device for selective stateless packet-based processing, packets entering the system are treated differently depending on certain conditions:

  • If a packet satisfies matching conditions specified in input filter terms, it is marked for packet mode and all configured packet mode features are applied to it. No flow-based security features are applied. It bypasses them.

  • If a packet has not been flagged for packet-mode, it undergoes normal processing. All services except for MPLS can be applied to this traffic.

Figure 2 shows traffic flow with selective stateless packet-based services bypassing flow-based processing.

Figure 2: Traffic Flow with Selective Stateless Packet-Based Services
Traffic
Flow with Selective Stateless Packet-Based Services

When the packet comes in on an interface, the input packet filters configured on the interface are applied.

  • If the packet matches the conditions specified in the firewall filter, a packet-mode action modifier is set to the packet. The packet-mode action modifier updates a bit field in the packet key buffer—this bit field is used to determine if the flow-based forwarding needs to be bypassed. As a result, the packet with the packet-mode action modifier bypasses the flow-based forwarding completely. The egress interface for the packet is determined through a route lookup. Once the egress interface for the packet is found, filters are applied and the packet is sent to the egress interface where it is queued and scheduled for transmission.

  • If the packet does not match the conditions specified in this filter term, it is evaluated against other terms configured in the filter. If, after all terms are evaluated, a packet matches no terms in a filter, the packet is silently discarded. To prevent packets from being discarded, you configure a term in the filter specifying an action to accept all packets.

A defined set of stateless services is available with selective stateless packet-based services:

  • IPv4 routing (unicast and multicast protocols)

  • Class of service (CoS)

  • Link fragmentation and interleaving (LFI)

  • Generic routing encapsulation (GRE)

  • Layer 2 switching

  • Multiprotocol Label Switching (MPLS)

  • Stateless firewall filters

  • Compressed Real-Time Transport Protocol (CRTP)

Although traffic requiring MPLS services must be processed in packet mode, under some circumstances it might be necessary to concurrently apply certain services to this traffic that can only be provided in flow mode, such as stateful inspection, NAT, and IPsec. To direct the system to process traffic in both flow and packet modes, you must configure multiple routing instances connected through a tunnel interface. One routing instance must be configured to process the packets in flow mode and the other routing instance must be configured to process the packets in packet mode. When you use a tunnel interface to connect routing instances, traffic between those routing instances is injected again into the forwarding path and it can then be reprocessed using a different forwarding method.

Selective Stateless Packet-Based Services Configuration Overview

This feature is supported on SRX300, SRX320, SRX340, SRX345, SRX550M, and SRX1500 devices. You configure selective stateless packet-based services using the stateless firewall filters, also known as access control lists (ACLs). You classify traffic for packet-based forwarding by specifying match conditions in the firewall filters and configure a packet-mode action modifier to specify the action. Once match conditions and actions are defined, firewall filters are applied to relevant interfaces.

To configure a firewall filter:

  1. Define the address family—First define the address family of the packets that a firewall filter matches. To define the family name, specify inet to filter IPv4 packets. Specify mpls to filter MPLS packets. Specify ccc to filter Layer 2 switching cross-connects.
  2. Define terms—Define one or more terms that specify the filtering criteria and the action to take if a match occurs. Each term consists of two components—match conditions and actions.
    • Match conditions—Specify certain characteristics that the packet must match for the action to be performed. You can define various match conditions, such as the IP source address field, IP destination address field, and IP protocol field.

    • Action—Specify what is to be done with the packet if it matches the match conditions. Possible actions are to accept, discard, or reject a packet; go to the next term; or take no action.

      You can specify only one action (or omit it) in a term, but you can specify any combination of action modifiers with it. Action modifiers include a default accept action. For example, if you specify an action modifier and do not specify an action, the specified action modifier is implemented and the packet is accepted.

      The packet-mode action modifier specifies traffic to bypass flow-based forwarding. Like other action modifiers, you can configure the packet-mode action modifier along with other actions, such as accept or count.

  3. Apply firewall filters to interfaces—Apply the firewall filter to the interface to have the firewall filter take effect.

When the packet comes in on an interface, the input packet filters configured on the interface are applied. If the packet matches the specified conditions and packet-mode action is configured, the packet bypasses the flow-based forwarding completely.

When configuring filters, be mindful of the order of the terms within the firewall filter. Packets are tested against each term in the order in which it is listed in the configuration. When the first matching conditions are found, the action associated with that term is applied to the packet and the evaluation of the firewall filter ends, unless the next term action modifier is included. If the next term action is included, the matching packet is then evaluated against the next term in the firewall filter; otherwise, the matching packet is not evaluated against subsequent terms in the firewall filter.

When configuring firewall filters for selective stateless packet-based services:

  • Accurately identify traffic that needs to bypass flow to avoid unnecessary packet drops.

  • Make sure to apply the firewall filter with packet-mode action on all interfaces involved in the packet-based flow path.

  • Make sure to configure host-bound TCP traffic to use flow-based forwarding—exclude this traffic when specifying match conditions for the firewall filter term containing the packet-mode action modifier. Any host-bound TCP traffic configured to bypass flow is dropped. Asynchronous flow-mode processing is not supported with selective stateless packet-based services.

  • Configure input packet filters (not output) with the packet-mode action modifier.

Note

Nested firewall filters (configuring a filter within the term of another filter) are not supported with selective stateless packet-based services.

Some typical deployment scenarios where you can configure selective stateless packet-based services are as follows:

  • Traffic flow between private LAN and WAN interfaces, such as for Intranet traffic, where end-to-end forwarding is packet-based

  • Traffic flow between private LAN and not-so-secure WAN interfaces, where traffic uses packet-based and flow-based forwarding for secure and not so secure traffic respectively

  • Traffic flow between the private LAN and WAN interface with failover to flow-based IPsec WAN when the private WAN link is down

  • Traffic flow from flow-based LAN to packet-based MPLS WAN

Example: Configuring Selective Stateless Packet-Based Services for End-to-End Packet-Based Forwarding

This example shows how to configure selective stateless packet-based services for end-to-end packet-based forwarding. This feature is supported on the SRX300, SRX320, SRX340, SRX345, SRX550M, and SRX1500 devices

Requirements

Before you begin:

  • Understand how to configure stateless firewall filters.

  • Establish basic connectivity. .

Overview

In this example, you configure the IP addresses for the interfaces on each of the devices. For R0 it is 10.1.1.2/24 ; for R1 they are 10.1.1.1/24, 10.2.1.1/24, and 203.0.113.1/30; for R2 it is 203.0.113.2/30; and for R3 it is 10.2.1.2/24. You create static routes and associate next-hop addresses for the devices as follows: R0 is 10.1.1.2, R1 is 198.51.100.2, R2 is 203.0.113.1, and R3 is 10.2.1.1.

Then on device R1 you configure a zone called untrust and assign it to interface ge-0/0/3. You also create a zone called trust and assign interfaces ge-0/0/1 and ge-0/0/2 to it. You configure trust and untrust zones to allow all supported application services as inbound services. You allow traffic from any source address, destination address, and application to pass between the zones.

You then create the firewall filter bypass-flow-filter and define the terms bypass-flow-term-1 and bypass-flow-term-2 that match the traffic between internal interfaces ge-0/0/1 and ge-0/0/2 and that contain the packet-mode action modifier. You define the term accept-rest to accept all remaining traffic. Finally, you apply the firewall filter bypass-flow-filter to internal interfaces ge-0/0/1 and ge-0/0/2 (not on the external interface). As a result, all internal traffic bypasses flow-based forwarding and the traffic to and from the Internet does not bypass flow-based forwarding.

Figure 3 shows the network topology used in this example.

Figure 3: Intranet Traffic Using End-to-End Packet-Based Services
Intranet
Traffic Using End-to-End Packet-Based Services

Your company’s branch offices are connected to each other through a private WAN. For this internal traffic, packet forwarding is required because security is not an issue. Hence for this traffic, you decide to configure selective stateless packet-based services to bypass flow-based forwarding. The remaining traffic, to and from the Internet, uses flow-based forwarding.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

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 the CLI User Guide.

To configure selective stateless packet-based services for end-to-end packet-based forwarding:

  1. Configure the IP addresses for the interfaces on devices R0, R1, R2, and R3.
  2. Create static routes and associate the appropriate next-hop addresses for devices R0, R1, R2, and R3.
  3. Configure security zones and assign interfaces.
  4. Configure application services for zones.
  5. Configure a security policy
  6. Create a firewall filter and define terms for all the packet-based forwarding traffic.
  7. Specify another term for the remaining traffic.
  8. Apply the firewall filter to relevant interfaces.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, and show firewall commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying the End-to-End Packet-Based Configuration

Purpose

Verify that the selective stateless packet-based services are configured.

Action

From configuration mode, enter the show interfaces, show routing-options, show security zones, show security policies, and show firewall commands.

Verify that the output shows the intended configuration of the firewall filter, interfaces, and policies.

Verify that the terms are listed in the order in which you want the packets to be tested. You can move terms within a firewall filter by using the insert command.

Verifying Session Establishment on Intranet Traffic

Purpose

Verify that sessions are established when traffic is transmitted to interfaces within the Intranet.

Action

To verify that sessions are established, perform the following tasks:

  1. On device R1, enter the operational mode clear security flow session all command to clear all existing security flow sessions.
  2. On device R0, enter the operational mode ping command to transmit traffic to device R3.
  3. On device R1, with traffic transmitting from devices R0 to R3 through R1, enter the operational mode show security flow session command.
Note

To verify established sessions, make sure to enter the show security flow session command while the ping command is sending and receiving packets.

Starting in Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1, the session flow summaries include CP session IDs.

The output shows traffic transmitting from R0 to R3 and no sessions are established. In this example, you applied the bypass-flow-filter with the packet-mode action modifier on interfaces Internal 1 and Internal 2 for your company’s Intranet traffic. This output verifies that the traffic between the two interfaces is correctly bypassing flow-based forwarding and hence no sessions are established.

Verifying Session Establishment on Internet Traffic

Purpose

Verify that sessions are established when traffic is transmitted to the Internet.

Action

To verify that traffic to the Internet is using flow-based forwarding and sessions are established, perform the following tasks:

  1. On device R1, enter the operational mode clear security flow session all command to clear all existing security flow sessions.
  2. On device R0, enter the operational mode ping command to transmit traffic to device R2.
  3. On device R1, with traffic transmitting from R0 to R2 through R1, enter the operational mode show security flow session command.
Note

To verify established sessions, make sure to enter the show security flow session command while the ping command is sending and receiving packets.

The output shows traffic transmitting from devices R0 to R1 and established sessions. In this example, you did not apply the bypass-flow-filter with the packet-mode action modifier on interface Internet for your company’s Internet traffic. This output verifies that the traffic to the Internet is correctly using flow-based forwarding and hence sessions are established.

Transmit traffic from device R3 to R2 and use the commands in this section to verify established sessions.

Example: Configuring Selective Stateless Packet-Based Services for Packet-Based to Flow-Based Forwarding

This example shows how to configure selective stateless packet-based services for packet-based to flow-based forwarding. This feature is supported on SRX300, SRX320, SRX340, SRX345, SRX550M, and SRX1500 devices.

Requirements

Before you begin:

  • Understand how to configure stateless firewall filters.

  • Establish basic connectivity. .

Overview

In this example, you configure the IP addresses for the interfaces on each of the devices. For device R0 as 198.51.100.9/24; for R1 the are198.51.100.10/24 and 203.0.113.5/24; and for R2 it is 203.0.113.9/24. On device R1, you set an internal service interface lt-0/0/0 between routing instances and configure a peer relationship between two virtual devices. You then create two security zones, Master-VR-zone and Internet-VR-zone, assign related interfaces to them, and configure them to allow all supported applications and protocols.

Then you configure policies and specify that all packets are permitted. You configure a virtual device routing instance Internet-VR and assign interfaces for flow-based forwarding. You enable OSPF on devices R0, R1, and R2. On Device R2, you configure the filter bypass-flow-filter with the term bypass-flow-term that contains the packet-mode action modifier. Because you have not specified any match conditions, this filter applies to all traffic that traverses the interfaces on which it is applied.

Finally, on device R1 you apply the firewall filter bypass-flow-filter to internal interfaces ge-0/0/2.0 and lt-0/0/0.0. You do not apply the filter to the interfaces associated with the Internet-VR routing instance. As a result, all traffic that traverses the LAN interfaces associated with the master routing instance uses packet-based forwarding and all traffic that traverses the Internet-VR routing instance uses flow-based forwarding.

Figure 4 shows the network topology used in this example.

Figure 4: Selective Stateless Packet-Based Services for Packet-Based Forwarding
Selective
Stateless Packet-Based Services for Packet-Based Forwarding

The interface facing the private LAN does not need any security services, but the interface facing the WAN needs security. In this example, you decide to configure both packet-based and flow-based forwarding for secure and not so secure traffic by configuring two routing instances—one handling the packet-based forwarding and the other handling the flow-based forwarding.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

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 the CLI User Guide.

To configure selective stateless packet-based services for end-to-end packet-based forwarding:

  1. Configure the IP addresses for the interfaces.
  2. Set an internal service interface between routing instances.
  3. Configure security zones.
  4. Configure policies.
  5. Configure a virtual device routing instance.
  6. Enable OSPF on all interfaces in the network.
  7. Create a firewall filter and define a term for packet-based forwarding traffic.
  8. Apply the firewall filter to relevant interfaces.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show security, show routing-instances, and show firewall commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying the Packet-Based to Flow-Based Configuration

Purpose

Verify that the selective stateless packet-based services are configured for packet-based to flow-based forwarding.

Action

From configuration mode, enter the show interfaces, show protocols, show security, show routing-instances, and show firewall commands.

Verify that the output shows the intended configuration of the firewall filter, routing instances, interfaces, and policies.

Verify that the terms are listed in the order in which you want the packets to be tested. You can move terms within a firewall filter by using the insert command.

Verifying Session Establishment on LAN Traffic

Purpose

Verify that the sessions are established when traffic is transmitted on interfaces within the LAN.

Action

To verify that sessions are established, perform the following tasks:

  1. On device R1, from operational mode enter the clear security flow session all command to clear all existing security flow sessions.
  2. On device R0, from operational mode enter the ping command to transmit traffic to device Master-VR.
  3. On device R1, with traffic transmitting from devices R0 through R1, from operational mode enter the show security flow session command.
Note

To verify established sessions, ensure that you enter the show security flow session command while the ping command is sending and receiving packets.

The output shows traffic transmitting from R0 to Master-VR and no sessions are established. In this example, you applied the bypass-flow-filter with the packet-mode action modifier on interfaces ge-0/0/0 and lt-0/0/0.0 for your company’s LAN traffic. This output verifies that the traffic between the two interfaces is correctly bypassing flow-based forwarding and hence no sessions are established.

Verifying Session Establishment on Internet Traffic

Purpose

Verify that sessions are established when traffic is transmitted to the Internet.

Action

To verify that traffic to the Internet is using flow-based forwarding and sessions are established, perform the following tasks:

  1. On device R1, from operational mode enter the clear security flow session all command to clear all existing security flow sessions.
  2. On device R0, from operational mode enter the ping command to transmit traffic to device R2.
  3. On device R1, with traffic transmitting from R0 to R2 through R1, from operational mode enter the show security flow session command.
Note

To verify established sessions, ensure that you enter the show security flow session command while the ping command is sending and receiving packets.

The output shows traffic transmitting from devices R0 to R2 and established sessions. In this example, you did not apply the bypass-flow-filter with the packet-mode action modifier on routing instance Internet-VR for your company’s Internet traffic. This output verifies that the traffic to the Internet is correctly using flow-based forwarding and hence sessions are established.

Note that sessions are established only when traffic is flowing between lt-0/0/0.1 and ge-0/0/3 and not when traffic is flowing between ge-0/0/2 and lt-0/0/0.0.

Understanding Session Cache

Overview

The SRX5K-MPC (IOC2), SRX5K-MPC3-100G10G (IOC3), and SRX5K-MPC3-40G10G (IOC3) on SRX5400, SRX5600, and SRX5800 devices support session cache and selective installation of the session cache.

Session cache is used to cache a conversation between the network processor (NP) and the SPU on an IOC. A conversation could be a session, GTP-U tunnel traffic, IPsec VPN tunnel traffic, and so on. A conversation has two session cache entries, one for incoming traffic and the other for reverse traffic. Depending on where the traffic ingress and egress ports are, two entries might reside in the same network processor or in different network processors. IOCs support session cache for IPv6 sessions.

A session cache entry is also called a session wing.

Session cache on the IOC leverages Express Path (formerly known as services offloading) functionality and helps prevent issues such as high latency and IPsec performance drop.

A session cache entry records:

  • To which SPU the traffic of the conversion should be forwarded

  • To which egress port the traffic of the conversion should be forwarded in Express Path mode

  • What processing to do for egress traffic, for example, NAT translation in Express Path mode

Starting with Junos OS Release 15.1X49-D10 and Junos OS Release 17.3R1, the session cache of the sessions in the IOC helps to solve certain performance issues. The SPU can now instruct the IOC session cache to forward subsequent traffic to a specific anchor SPU.

Starting with Junos OS Release 15.1X49-D10, the SRX5K-MPC (IOC2) and the IOC3 support VPN session affinity through improved flow module and session cache. Starting in Junos OS Release 12.3X48-D30, on the IOC2, VPN session affinity through session cache is supported.

Other traffic was hashed to SPUs based on their 5-tuple key information. VPN traffic employed the concept of the anchored SPU, which did not necessarily coincide with the functions of the flow SPU. The network processor could only forward the packets to the flow SPU based on the 5-tuple hash. The flow SPU then forwarded the packet to the anchored SPU. This created an extra hop for VPN traffic, which wasted the switch fabric bandwidth and reduced the VPN throughput roughly by half. This performance reduction occurred because the traffic still had to go back to the flow SPU after processing on the anchored SPU.

The session cache table is now extended on IOC to support the NP sessions. Express Path traffic and NP traffic share the same session cache table on IOCs. Express Path traffic is forwarded by the IOC itself either locally or to another IOC, because the traffic does not require any services from the SPU. NP traffic is forwarded to the SPU specified in the session cache for further processing. All the session cache entries are shared by both Express Path session traffic and NP traffic.

To enable session cache on the IOCs you need to run the set chassis fpc <fpc-slot> np-cache command.

Note

The IOC2 and the IOC3 utilize the delay sessions delete mechanism. The same sessions (sessions with the same five tuples) that are deleted and then reinstalled immediately are not cached on the IOCs.

Selective Session Cache Installation

To avoid high latency, improve IPSec performance, and to better utilize the valuable resources, certain priority mechanisms are applied to both flow module and the IOC.

The IOCs maintain and monitor session cache usage threshold levels. The IOCs also communicate the session cache usage to the SPU, so that when a certain session cache usage threshold is reached, the SPU only sends session cache installation requests for selective high-priority traffic sessions.

Applications like IDP, ALG need to process packets in order. One SPU has multiple flow threads to handle packets belong to one session, LBT, POT packet order can make sure traffic pass through firewall in order, it cannot guarantee application to process packets that belong to same session in order. Flow serialization provides the method that only one SPU flow thread processing packets belong to the same session at one time, so applications can receive, process and send out packet in order. Other flow threads can do flow serialization processing for other sessions at the same time.

The following three priority levels are used to determine which type of traffic can install session cache on the IOCs:

  • Priority 1 (P1)—Express Path qualified traffic

  • Priority 2 (P2)—IPsec tunneling, Fragmentation ordering, and NAT/SZ (Session serialization) traffic

  • Priority 3 (P3)—All other types of traffic

The IOCs maintain and monitor the threshold levels for session cache usage and update the current real-time session cache usage to the SPU. The SPU requests the IOC to install the session cache for certain high-priority traffic sessions. Session cache usage for high-priority traffic sessions is defined in table:

Table 1: Session Cache Installation Bars

Traffic Type

Green

Yellow

Orange

Red

Express Path traffic

Yes

Yes

Yes

Yes

IPsec Fragmentation traffic

Yes

Yes

Yes

No

NAT/SZ traffic

Yes

Yes

No

No

Other traffic

Yes

No

No

No

To conserve session entries on the IOC, the flow module selectively installs sessions on the IOC. To facilitate the session install selection, the IOC maintains corresponding thresholds to provide an indication to the flow module (on how full the session cache table is on the IOCs).Two bits in the meta header (see Table 2) are added to indicate the current cache table utilization status. All packets going to the SPU will carry these two status bits to inform the flow module of the utilization of the cache table on the IOC.

Table 2 shows the cache table utilization (CTU) bits and the respective session cache table utilization.

Table 2: Session Cache Table Utilization Bits Status

Session Cache Table Utilization (CTU) Bits

IOC Session Cache/Express Path Table Utilization

Action

00

0% < utilization < 25%

Flowd installs any eligible session.

01

25% < utilization < 50%

Flowd installs only high-priority sessions, such as Express Path, IPsec, IPsec clear-text, NAT, SZ, and fragmented sessions.

10

50% < utilization < 75%

Flowd installs only Express Path sessions, IPsec, IPsec clear-text, and fragmented sessions.

11

75% < utilization < 100%

Flowd installs only the Express Path sessions.

IPsec VPN Session Affinity Enhancement Using Session Cache

SRX Series devices are fully distributed systems, and an IPsec tunnel is allocated and anchored to a specific SPU. All the traffic that belongs to an IPsec tunnel is encrypted and decrypted on its tunnel-anchored SPU. In order to achieve better IPsec performance, IOC improves the flow module to create sessions for IPsec tunnel-based traffic (before encryption and after decryption) on its tunnel-anchored SPU, and installs session cache for the sessions so that the IOC can redirect the packets directly to the same SPU to minimize packet-forwarding overhead. Express Path traffic and NP traffic share the same session cache table on IOCs.

You need to enable session cache on the IOCs and set the security policy to determine whether a session is for Express Path (formerly known as services offloading) mode on the selected Flexible PIC Concentrator (FPC).

To enable IPsec VPN affinity use, the set security flow load-distribution session-affinity ipsec command.

Note

To enable IPsec VPN affinity, you must also enable the session cache on IOCs by using the set chassis fpc <fpc-slot> np-cache command.

Fragmentation Packet Ordering Using NP Session Cache

A session might consist of both normal and fragmented packets. With hash-based distribution, 5-tuple and 3-tuple key can be used to distribute normal and fragmented packets to different SPUs, respectively. On SRX Series devices, all the packets of the session are forwarded to a processing SPU. Due to forwarding and processing latency, the processing SPU might not guarantee packet ordering of the session.

Session cache on the IOCs ensure ordering of packets of a session with fragmented packets. A session cache entry is allocated for normal packets of the session and a 3-tuple key is used to find the fragmented packets. On receipt of the first fragmented packet of the session, the flow module allows the IOC to update the session cache entry to remember the fragmented packets for the SPU. Later, IOC forwards all subsequent packets of the session to the SPU to ensure ordering of packets of a session with fragmented packets.

Related Documentation

Release History Table
Release
Description
Starting in Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1, the session flow summaries include CP session IDs.
Starting with Junos OS Release 15.1X49-D10 and Junos OS Release 17.3R1, the session cache of the sessions in the IOC helps to solve certain performance issues.
Starting with Junos OS Release 15.1X49-D10, the SRX5K-MPC (IOC2) and the IOC3 support VPN session affinity through improved flow module and session cache
Starting in Junos OS Release 12.3X48-D30, on the IOC2, VPN session affinity through session cache is supported