Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Express Path

 

Express Path (formerly known as services offloading) is a mechanism for processing fast-path packets in the network processor instead of in the Services Processing Unit (SPU). This method reduces the packet-processing latency that arises when packets are forwarded from network processors to SPUs for processing and back to I/O cards (IOCs) for transmission.

Express Path Overview

Understanding Express Path Functionality

This feature is supported on SRX5400, SRX5600, and SRX5800 devices.

Express Path considerably reduces packet-processing latency by 500–600 percent.

When the first packet arrives at the interface, the network processor forwards it to the SPU. If the SPU verifies that the traffic is qualified for Express Path, an Express Path session is created on the network processor. If the traffic does not qualify for Express Path, a normal session is created on the network processor. If an Express Path session is created, the subsequent fast-path packets are processed in the network processor itself.

Note

A normal session forwards packets from the network processor to the SPU for fast-path processing, whereas an Express Path session processes fast-path packets in the network processor and the packets exit out of the network processor itself.

When an Express Path session is created on the network processor, subsequent packets of the flow match the session on the network processors. The network processor then processes and forwards the packet. The network processor also handles additional processing such as TCP sequence check, time to live (TTL) processing, Network Address Translation (NAT), and Layer 2 header translation.

The network processor forwards packets to the SPU in the following cases:

  • When the first packet arrives at the interface, the network processor forwards it to the central point (CP). The central point in turn forwards the packet to the SPU. The SPU then creates a session on the network processor.

  • When an SPU session exists even if no network processor session exists, the network processor forwards a packet to the central point, which in turn forwards the packet to the SPU. The SPU then creates a session on the network processor.

  • When a packet matches a normal session on the network processor, it is forwarded to the SPU.

Starting with Junos OS Release 12.3X48-D10 and Junos OS Release 17.3R1, a license is no longer required to enable Express Path functionality. Your previously acquired license will not be effective anymore. (Prior to Junos OS Release 12.3X48-D10, Express Path was a licensed software feature.)

Starting with Junos OS Release 15.1X49-D60 and Junos OS Release 17.3R1, SRX5400, SRX5600, and SRX5800 devices with the SRX5K-MPC (IOC2), SRX5K-MPC3-100G10G (IOC3), and SRX5K-MPC3-40G10G (IOC3) support Express Path (formerly known as services offloading) for ALG traffic.

The following ALG data traffic that supports Express Path—FTP, H.323 (only RTP/RTCP sessions are offloaded), MGCP, MS RPC, RSH, RTSP, SCCP, SIP (only RTP/RTCP sessions are offloaded), SUN RPC, TALK (only TCP sessions are offloaded), and TFTP.

DNS, IKE and ESP, PPTP, and SQL-NET ALG data traffic do not support Express Path.

Once an Express Path session is setup, packets cannot be sent to the SPU again.

Understanding Express Path Support on SRX Series Devices

Table 1 provides details about the Express Path support on different SRX Series cards.

Table 1: Express Path Support on SRX Series Device Cards

SRX Series Device

Card Name and Model Number

Earliest Supported Release

SRX5000 Line Devices I/O Cards (IOCs)

SRX5600, SRX5800

SRX5K-40GE-SFP

Junos OS Release 11.4

SRX5600, SRX5800

SRX5K-4XGE-XFP

Junos OS Release 11.4

SRX5600, SRX5800

SRX5K-FPC-IOC containing one of the following cards:

  • SRX-IOC-16GE-TX

  • SRX-IOC-4XGE-XFP

  • SRX-IOC-16GE-SFP

Junos OS Release 11.4

SRX5400, SRX5600, SRX5800

SRX5K-MPC containing one of the following MICs:

  • SRX-MIC-10XGE-SFFP

  • SRX-MIC-2X40GE-OSFP

  • SRX-MIC-1X100GE-CFP

  • SRX-MIC-20GE-SFP

Junos OS Release 12.3X48-D10

SRX5400, SRX5600, SRX5800

SRX5K-MPC3 (IOC3) containing one of the following MPCs:

  • SRX5K-MPC3-40G10G (24x10GE + 6x40GE MPC)

  • SRX5K-MPC3-100G10G (2x100GE + 4x10GE MPC)

Junos OS Release 15.1X49-D10

Note

Different Express Path features are supported on different cards for different Junos OS releases. See the Junos OS Release Notes for details.

Note

On the SRX5600 and SRX5800 Services Gateways, the Express Path sessions for traffic that traverse between legacy IOC cards and the SRX5K-MPC or the SRX5K-MPC3 are not supported.

The Express Path sessions traversing only on legacy IOC cards or only on the SRX5K-MPC (IOC2), the SRX5K-MPC3-100G10G (IOC3), or the SRX5K-MPC3-40G10G (IOC3) are supported. However, the SRX5K-MPC (IOC2), the SRX5K-MPC3-100G10G (IOC3), the SRX5K-MPC3-40G10G (IOC3), and the legacy IOCs can still be present on the same chassis.

Understanding Express Path Features

Wing Statistics Counter

The network processor in Express Path mode provides the option for each flow entry to keep a per-wing bytes counter. The counter captures the number of bytes that the network processor sends out over the wing.

When the counter is enabled, for every ingress packet, the network processor searches its flow entry (a session wing). If the packet belongs to an established flow entry, the network processor increases the byte counter of the flow entry by byte count in the packet. The network processor periodically copies a packet (called a copy-packet) of each flow entry to its associated SPU, allowing the SPU to maintain the session. The network processor sends flow byte counter values in the header of copy-packet packets. The SPU accumulates and keeps per-wing statistics counters.

Note

The counter value carried to the SPU is always one packet short to allow the SPU to add the current packet’s byte count to the counter to get the correct total. For example, if packet N’s copy carries a counter value to the SPU, the counter value is the total bytes received in the flow up to packet N-1.

The counter value does not include packets that were sent before the session was set up on the network processor. Therefore, the SPU might need to account for the three-way handshake packet and other packets sent through the SPU. The actual session byte counter shown on the SPU might be short by the amount of bytes sent by the client during the copy interval. This discrepancy results because these bytes can be counted locally by the network processor, but have not yet been reported to the SPU.

Note

You cannot change the statistics configuration during the life cycle of a live session. Disabling or enabling the per-wing statistics configuration while a session is alive at the network processor invalidates the session statistics on the current session. The new sessions statistics can be valid only after the configuration changes are committed . Network processor per-wing counters cannot be cleared.

Note

Wing statistics counter configuration is enabled, by default, on SRX5800 devices with the SRX5K-MPC (IOC2) and the SRX 5K-MPC3 (IOC3).

Sessions per Wing Statistics

The NP-IOC has a larger static RAM (SRAM) to accommodate session resources, thus hosting more sessions per PIC. Table 2 displays the total number of session wings, including both Express Path and non-Express Path.

Table 2: Total Number of Sessions per Wing in Network Processor Express Path Configuration Mode

Total Number of Wings

Number of Express Path UDP Wings

Number of Express Path TCP Wings

Cards and SRX Series DeviceNon-Express Path Mode SessionsWithout StatisticsWith StatisticsWithout StatisticsWith Statistics

IOC

1.3 million

1.3 million

900,000

600,000

400,000

FIOC

2.3 million

198,000

900,000

600,000

400,000

SRX5000 line device SRX5K-MPC

NA

1.8 million

1.8 million

1.8 million

1.8 million

SRX5000 line device SRX5K-MPC3 (IOC3)

NA

2.0 million

2.0 million

2.0 million

2.0 million

Cross-Network Traffic

Express Path provides additional cross-network-processor support; therefore, it is no longer restricted to the ports of the same network processor. If network processors for both the ingress and egress ports are in Express Path mode, then Express Path packets are directly forwarded from the ingress network processor to the egress network processor in the fast-flow path. Packets cross switch fabric when they are forwarded from one network processor to another, thus increasing the latency of the packet. In Express Path mode, the latency of cross-network-processor packets is higher than the packets that are forwarded within an individual network processor.

Note

The SRX5K-MPC receives session messages from the SPU. The session messages carry the information to support inter- and intra-Packet Forwarding Engine Express Path for IPv4.

LAG Support in Express Path Mode

Ethernet link aggregation groups (LAGs) combine links and provide increased bandwidth and link availability. Express Path reduces packet latency by processing and forwarding packets in the network processor instead of in the Services Processing Unit (SPU). Supporting LAG in the Express Path mode combines the benefits of both these features and provides enhanced throughput, link redundancy, and reduced packet latency.

LAG Links Qualifying for Express Path Mode

You can use the links in a LAG as ingress or egress interfaces in Express Path mode. The LAG links can include links from different network processors (in case of legacy cards such as IOCs or Flex IOCs) or from the same modular port concentrator (in case of SRX5K-MPC). For a LAG link to qualify for Express Path, all its member links should be connected to Express Path-enabled network processors. If Express Path is disabled on any of the member links in a LAG, a regular session (non-Express Path session) is created. Also, LAG links are not supported between legacy cards such as IOCs or Flex IOCs and the SRX5K-MPC.

LAG and Network Processor Wings

The network processor checks the egress interface in the Express Path mode for each wing. Per-wing traffic distribution over a LAG interface is achieved by letting the SPU install wings pointing to egress interfaces with a balanced distribution.

The network processor periodically copies a packet (called a copy-packet) to the SPU, allowing it to maintain the session. The copy-packet contains the egress interface information, which the SPU uses to handle LAG member change cases; for example, when a link is down or disabled. When there is no member interface that can be used as an egress interface for transmitting traffic, the network processor session is updated from Express Path to non-Express Path and the packet is sent to the SPU. A new Express Path network processor session is then installed using a new, valid egress interface.

  • First wing—On the egress interface, the SPU selects one LAG active member link as the outgoing interface for a specific fast-forward session. The SPU treats this active member interface just like any physical interface in the Express Path mode and records the interface to the network processor fast-forward session. After that, all traffic that matches this network processor session is directly transmitted through that member link.

  • Reverse wing—the reverse network processor session is installed only when all LAG member links are connected to a single network processor. When member links of a LAG are from multiple network processors, the reverse network processor session is initiated by reverse traffic later (it is not preinstalled).

    The Express Path network processor session needs to have outgoing interface information to send traffic. If the incoming interface is a physical interface, then it can be used as an outgoing interface for the reverse wing. However, if the incoming interface is an aggregated Ethernet interface, the SPU selects a member interface to be the outgoing interface.

LAG and Network Processor Session Updates

Some changes in the LAG interfaces can cause network processor session updates:

  • LAG interface status changes—The LAG interface status can change due to several reasons—for example, when member interfaces are deleted, when an interface is down, or when an active LAG member is removed. In such cases, a session scan is triggered and network processor sessions related to the LAG interface are removed. The packet then installs a new network processor session, which could be a fast-forward session, if it qualifies.

  • An active member is deactivated or removed from the LAG—In cases when the LAG still has an active member, neither a reroute nor session scan is triggered. The traffic is redistributed on the failed LAG member by monitoring outgoing logical interface status in the SPU.

  • A new member is added to the LAG—The network processor session is not updated. A new network processor session is created, which might use the newly added interface or not, depending on the member selection algorithm for the LAG.

Redistribution of Traffic on a Failed LAG Interface

When a LAG member fails, the traffic needs to be redistributed. To redistribute traffic, the system monitors the status of the egress interface in the SPU. When the system detects a failure, it updates the Routing Engine kernel, and passes the physical interface information down to all SPUs. On receiving a copy of the session, the SPU extracts the egress interface index and checks the physical interface information. If the physical interface is down, the SPU uninstalls the session and the ingress network processor deletes the session cache.

For the next ingress packet of the same conversation, the network processor forwards the packet to the SPU to select an active member interface in the LAG as an egress interface. The SPU performs the distribution algorithm to select a new egress interface. A new session with the new egress interface index is installed in the ingress network processor and a new fast-flow path is created.

End-to-End Debugging

For regular flow packets, end-to-end debugging functions are the same as in the non-Express Path mode; packet filter and action items are supported in this flow mode. For traffic that matches Express Path sessions, the end-to-end debugging function supports one packet copy to the host CPU when the filter and the action are both affirmative in the end-to-end search results.

Note

End-to-end debugging is not supported on the SRX5K-MPC when Express Path mode is enabled.

Per-Session Statistics CLI

To enable the per-session statistics, copy and paste the following command into the CLI at the [edit] hierarchy level.

Verify that the services-offload per-session-statistics command is enabled.

show configuration chassis
Note

The services-offload per-session-statistics command is not applicable for the SRX5K modular port concentrators when Express Path is configured, because every session has statistics by default.

Use the show chassis hardware command to display hardware information.

show chassis fpc pic-status (SRX5600 and SRX5800 devices When Express Path [Services-Offload] is Configured)

user@host> show chassis fpc pic-status

Express Path Limitations

The Junos OS Express Path implementation has the following limitations.

  • Unsupported features—The following features are not supported with Express Path:

    • Transparent mode is not supported. If transparent mode is configured, a normal (non-Express Path) session is installed.

    • Only multicast sessions with one fan-out are supported. If a multicast session with more than one fan-out exists, a normal session is installed.

    • Only active/passive chassis cluster configuration is supported. Active/active chassis cluster configuration is not supported.

    • Fragmented packets are not supported. If fragmented packets exist, a normal session is installed.

    • Express Path is not supported in IPsec VPN, and IDP configurations. Normal flow sessions will be used in these scenarios.

    • Express Path does not support cross logical system traffic, regular flow sessions are used for cross logical system traffic processing and forwarding.

    • Starting in Junos OS 15.1X49-D40 and Junos OS Release 17.3R1, IPv6 is supported. Prior to Junos OS 15.1X49-D40, IPv6 support is limited, and if IPv6 is configured, a normal session is installed.

    • When Express Path mode is enabled on an SRX5K-MPC, you might not be able to enable the firewall filter. In general, all processes related to J-Flow (versions 5, 8, and 9) in an SRX Series device take place in the SPU. In Express Path security flow sessions, the J-Flow configuration will not take effect.

    • Class of service (CoS) on egress interfaces is not supported.

    • Configuration of protection against a teardrop (Screen) attack is not supported when Express Path is enabled.

    • Configuring different MTU size values is not supported on the SRX5K-MPC when Express Path is enabled.

  • Performance drop—The following drops in performance occur when Express Path is enabled:

    • Normal (non-Express Path) sessions—When Express Path is enabled, for normal sessions, the performance can drop by approximately 20 percent for connections per second (CPS) and 15 percent for packets per second (pps) when compared with normal sessions.

    • Express Path sessions—When Express Path is enabled, for fast-forward sessions, the performance can drop by approximately 13 percent for connections per second (CPS).

  • Chassis cluster—When the device is operating in chassis cluster mode:

    • Asymmetric IOC configuration is not supported when Express Path is enabled on a device operating in chassis cluster mode.

    • If a child link goes down from the LACP-enabled redundant Ethernet interface of an IOC with Express Path enabled on its FPC, all traffic on this link is distributed to other active child links of the interface. If the child link comes up and rejoins the redundant Ethernet interface, then the existing traffic or sessions might not be redistributed over this newly rejoined active child link. New sessions might however traverse through this link.

    • If a new child link is added on the LACP-enabled redundant Ethernet interface of an IOC with Express Path enabled on its FPC, then the existing traffic or sessions might not be redistributed over this new child link. New sessions might however traverse through this link.

  • For the normal flow sessions, the show security flow session command displays bytes counters based on IP header length. However for sessions in Express Path mode, the statistics is collected from IOC2 and IOC3 ASIC hardware engine, and includes full packet length with L2 headers. So the show security flow session command output displays slightly larger bytes counters for sessions in Express Path mode than the normal flow session.

Express Path Support on NP-IOC Card

The NP-IOC card integrates an existing I/O card (IOC) with a Network Processing Card (NPC) in one card with simplified Layer 2 functions in the hardware. This new hardware changes the way the interface is interpreted in the system.

Note

Each interface in the NP-IOC card can only be attached to the network processor on the NP-IOC card. This fixed attachment setup requires the network processor to manage the interfaces as local or relative interfaces, instead of systemwide global interfaces.

Besides providing physical layer network connections, another function of the NP-IOC card is to distribute packets coming into the physical ports to the Services Processing Units (SPUs) and to forward packets out of the physical ports. For parallel security processing, flow sessions are assigned to multiple SPUs, based on a load balance algorithm. The network processor on the NP-IOC is responsible for directing traffic to the proper SPU based on the session table installed in its local memory.

In Express Path mode, the first packet is processed as is, meaning the packet is forwarded to the central point and the central point assigns an SPU and passes the packet to the SPU. For packets in fast-path, instead of forwarding all packets to the SPU, the network processor forwards the packets to an egress network processor, which can be different from or the same as the ingress network processor.

Express Path Support on SRX5K Modular Port Concentrator

The SRX5K-MPC is a Modular Port Concentrator (MPC) that is supported on the SRX5400, SRX5600, and SRX5800.

The SRX5K-MPC is an interface card with two slots that accept MICs, which add Ethernet ports to your services gateway. An MPC with MICs installed functions in the same way as a regular I/O card (IOC) but allows you to add different types of Ethernet ports to your device.

Each MPC is equipped with Trio chipsets, which perform control functions tailored to the MPC’s media type.

When a Trio chipset receives the first packet, the packet is forwarded to an SPU based on the hash value (which is determined by a hash function of the 5 tuples of the session).

If the SPU verifies that the traffic is qualified for Express Path (formerly known as services offload), an Express Path session is created on the Trio chipset. If the traffic does not qualify for Express Path, it is forwarded by default hash-based forwarding to SPUs. If an Express Path session is created, the subsequent fast-path packets are processed in the Trio chipset itself.

The Trio chipset performs all the necessary checks to forward the packet, including TTL checking and decreasing, TCP sequence check, NAT translation, and Layer 2 header encapsulation. In addition, the Trio chipset sends a session refresh message to the SPU every second. This message is used to refresh the SPU session, detect the current state of the Trio chip set and update SPU session statistics.

The session table on the SRX5K-MPC, managed by the SPU, provides the following functions:

  • Flow insert or delete

  • Flow lookup

  • Flow aging

  • Flow statistics

The SPU inserts and deletes flow entries in the session table based on policy matching results.

Note

Configuring the screen options on an SRX5K-MPC when operating in Express Path mode is the same as when the card is operating in normal mode.

Express Path Support on SRX5K-MPC3-100G10G (IOC3) and SRX5K-MPC3-40G10G (IOC3)

Express Path (formerly known as services offload) on the IOC3 is based on processing fast-path packets through the Trio chipset instead of in the SPU to offload some basic firewall functions to the IOC3.

When the Express Path feature is enabled, the IOC3 provides much lower latency, and also supports higher throughput by removing the overload on the SPU. The IOC3 supports both intra-card traffic flow and inter-card traffic flow. To achieve the best latency results, both the ingress port and egress port of a traffic flow need to be on the same XM chip of the IOC3.

Starting with Junos OS Release 15.1X49-D80, two new system log messages have been added to indicate memory-related problems on the interfaces to the DDR3 memory.

These system log messages are:

  • XMCHIP_CMERROR_DDRIF_INT_REG_CHKSUM_ERR_MINOR

  • XMCHIP_CMERROR_DDRIF_INT_REG_CHKSUM_ERR_MAJOR

The error messages indicate that the XMCHIP on an Flexible PIC Concentrator (FPC) has detected a checksum error, which is causing packet drops. The following error threshold values classify the error as a major error or a minor error:

  • Minor error —> 5 errors per second

  • Major error —> 255 errors per second (maximum count)

The flow table on the IOC3 is managed by the SPU of the flow module. The SPU inserts and deletes flow entries in the flow table based on policy matching results. In the data plane, the IOC3 parses packets, and looks them up in the flow table. If the IOC3 finds a match in the flow table, then it forwards packets based on the instructions given in the flow table. The IOC3 can perform NAT, encapsulate the Level 2 (L2) header, and forward the packets out of the egress interface. The egress interface can be located on the same IOC3 (intra-card case) or on another IOC3 (inter-card case).

Note

Flow table lookup in the IOC3 occurs only in ingress. Egress datapath packet handling is the same as supported in the previous release.

When the IOC3 receives the first packet, it does not match any existing fast-forward session. The default hash-based forwarding is performed to send the first packet to the SPU. The SPU then creates the security session. If the SPU finds that the traffic is qualified for fast forwarding, and the related IOC3 supports fast forwarding, it will install fast-forward session to the IOC3. If fast forwarding cannot be applied to the traffic, no session message is sent, and the IOC3 uses the default hash-based forwarding to forward the packets to the SPU.

In fast-forward IOC3 processing, if a fast-forward session is matched, the packet can be directly forwarded according to the session flow result. The IOC3 takes all the necessary actions, including forwarding the packet, TTL checking and decreasing, NAT translation, L2 header encapsulation and so on.

In addition, the XL chip sends one copy of the forwarding packet to the SPU at every predefined time. This copy is used to refresh the SPU session, detect the current XL chip state, and so on. The SPU consumes this packet and does not forward it, because the real packet has been processed and transmitted.

Expres Path support on IOC3 is illustrated in Figure 1, Figure 2, and Figure 3.

Figure 1: IOC3 Intra-PFE Express Path
IOC3 Intra-PFE Express
Path
Figure 2: IOC3 Inter-PFE Express Path
IOC3 Inter-PFE Express
Path
Figure 3: Inter-IOC3 Express Path
Inter-IOC3 Express
Path

IPv6 Flow in Express Path Mode for IOC2 and IOC3

IPv6 traffic is supported on SRX5000 line devices with the SRX5K-MPC (IOC2), the SRX5K-MPC3-100G10G (IOC3), or the SRX5K-MPC3-40G10G (IOC3) in Express Path mode.

On SRX5000 line devices, Express Path for IPV6 traffic is not supported on legacy IOC cards. However, IPv6 regular flow mode is supported on legacy IOCs.

When an Express Path session is created on the network processor, subsequent packets of the flow match the session on the network processors. The network processor then processes and forwards the packet. The network processor also handles additional processing such as TCP sequence check, time-to-live (TTL) processing, and Layer 2 header translation.

The following features are not supported in Express Path mode:

  • IPv6 NAT

  • Transparent mode

  • Configuring different MTU size values

  • Class of Service (CoS) on egress interfaces

Note the following limitations:

  • Express Path sessions for IPv6 traffic traversing on legacy IOC cards is not supported. IOC2 and IOC3 does not support IPv6 traffic in Express Path sessions when traffic traverse between legacy IOC and IOC2 or IOC3. Normal IPv6 traffic is still supported in this scenario.

  • A redundant Ethernet interface must contain both child interfaces from the same IOC type. For example, if one child link is from 10-Gigabit Ethernet on IOC2, the second child link should also be from the IOC2. Similarly, both child interfaces can be from IOC3. Configuring child interfaces by mixing the links from both IOC2 and IOC3 is not supported.

IPv6 Flow in Express Path Mode

IPv6 traffic is supported on SRX5000 line devices with SRX5K-MPC (IOC2), the SRX5K-MPC3-100G10G (IOC3), or the SRX5K-MPC3-40G10G (IOC3). All IPv6 traffic is handled in regular flow mode, meaning that packets are forwarded to the SPU for flow processing. Egress IPv6 traffic is also forwarded from the SPU to the network processor, and then the network processor handles this traffic as regular flow traffic in the egress path.

When an Express Path session is created on the network processor, subsequent packets of the flow match the session on the network processors. The network processor then processes and forwards the packet. The network processor also handles additional processing such as TCP sequence check, time to live (TTL) processing, Network Address Translation (NAT), and Layer 2 header translation.

Note

On the SRX5000 line devices, the Express Path sessions for IPv6 traffic that traverse between legacy IOC cards and not supported.

The Express Path sessions for IPv6 traffic traversing only on legacy IOC cards or only on the SRX5K-MPC (IOC2), the SRX5K-MPC3-100G10G (IOC3), or the SRX5K-MPC3-40G10G (IOC3) are supported.

Understanding the Express Path Solution

The high-end SRX Series devices have long packet-processing latency because the packets are processed through the Services Processing Unit (SPU) and through several stages of buffers in the data path.

This feature introduces a local forwarding solution where the fast-path packets are processed by the network processor on the I/O Card (IOC), without going through the switch fabric or the SPU. This solution reduces the packet-processing latency.

The behavior of the network processor in different scenarios is as follows:

  • First-path flow—The first-path flow is the same as the current network processor flow process. When the first packet arrives at the network processor, the network processor parses the TCP or the UDP packet to extract a 5-tuple key and then performs session lookup in the flow table. The network processor then forwards the first packet to the central point. The central point cannot find a match at this time, because this is the first packet. The central point and the SPU create a session and match it against user-configured policies to determine if the session is a normal session or a services-offload session.

    If the user has specified the session to be handled with services offload, the SPU creates a session entry in the network processor flow table, enabling the services-offload flag in the session entry table; otherwise, the SPU creates a normal session entry in the network processor without the services-offload flag.

  • Fast-path flow—After the session entry is created in the network processor, subsequent packets of the session will match the session entry table.

    • If the services-offload flag is not set, then the network processor forwards the packet to the SPU specified in the session entry table. The packet goes through the normal flow process.

    • If the network processor finds the services-offload flag in the session entry table, it will process the packet locally and send the packet out directly.

    Note

    The fast-forwarding function on the network processor supports one-fanout multicast sessions. The egress port in the session must also be associated with the same network processor of the ingress port. All other multicast cases need to be handled as normal sessions.

  • NAT process—The SPU is responsible for mapping between the internal IP address or port and the external IP addres or port. When the first packet of the session arrives, the SPU allocates the IP address or port mapping and stores the information in the network processor session entry. The network processor does the actual packet modification if the NAT flag is set.

  • Session age-out—To improve traffic throughput for services-offload sessions, a copy of a packet is sent to the SPU at every predefined time period to reduce the packet processing demand on the SPU. To limit the number of packet copies sent to the SPU, a timestamp is implemented for each services-offload session. This enables the network processor to calculate the elapsed time since the last session match. If the elapsed time is greater then the predefined time period, then the network processor sends a copy of the packet to the SPU, and updates the session timestamp.

  • Session termination and deletion—If the network processor receives an IP packet with a FIN (finished data) or a RST (reset connection) flag, it forwards the packet to the SPU. The SPU then deletes the session cache on network processor. The network processor continues to receive and forward any packets to the SPU during state transition.

Enabling and Disabling Express Path

Express Path (formerly known as services offloading) is a mechanism for processing fast-path packets in the network processor instead of in the Services Processing Unit (SPU). This method reduces the packet-processing latency that arises when packets are forwarded from network processors to SPUs for processing and back to I/O cards (IOCs) for transmission.

Note

Starting with Junos OS Release 12.3X48-D10 and Junos OS Release 17.3R1, the Express Path license is no longer required to enable the Express Path functionality. Your previously acquired Express Path license will not be effective anymore. (Prior to Junos OS Release 12.3X48-D10, Express Path was a licensed software feature, formerly known as “services offloading.”)

  • When device is operating in chassis cluster mode, you need to reboot both the nodes when changing FPC(s) to Express Path mode.

  • During initialization, when a network processor is configured to perform Express Path, then the FPC CPU will load a special image to the network processor.

You can enable Express Path mode as follows:

  • Set the Express Path mode on the selected card.

  • Reboot the device containing the Express Path network processor to load the Express Path firmware image on the network processors.

  • Configure a policy to define the traffic that should take fast-path.

To configure the Express Path mode:

  • For configuring Express Path on an SRX5000 line device with a IOC1 or FIOC cards, use the set chassis fpc fpc-number pic pic-number services-offload command.

  • For configuring Express Path on an SRX5000 line device with Modular Port Concentrator (MPC), enable NP cache on the IOC using the set chassis fpc fpc-number np-cache command.

    Note

    The set or delete chassis fpc fpc-number services-offload command is deprecated.

  • To disable Express Path on an SRX5000 line device with Modular Port Concentrator (MPC), use the delete chassis fpc fpc-number np-cache command.

  • Reboot the device when Express Path is disabled.

Example: Enabling Express Path in Security Policies

This example shows how to enable Express Path (formerly known as services offloading) in security policies.

Requirements

Before you begin, understand the Express Path overview..

Overview

In this example, you enable Express Path in security policies to specify whether the traffic qualifies for Express Path.

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, 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 Express Path in policies:

  1. Configure a policy to process the traffic that goes to the HTTP static ports.
  2. Enable Express Path in the security policy.

Results

From configuration mode, confirm your configuration by entering the show security policies command. 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

Verifying Express Path in Policies

Purpose

Verify that Express Path is enabled.

Action

From operational mode, enter the show security policies command.

Example: Configuring an IOC on SRX5000 Line Devices to Support Express Path

This example shows how to configure an IOC on SRX5000 line of devices to support Express Path (formerly known as services offloading).

Requirements

Before you begin, understand the Express Path overview.

Overview

In this example, you configure the IOC on SRX5000 line devices to perform Express Path.

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.

Note

For SRX5000 line devices, the IOC slot number is 3.

Step-by-Step Procedure

To configure the IOC you need to run the following commands:

  1. Set the services offload mode on the IOC.
    [edit]

    user@host# set chassis fpc 3 pic 0 services-offload
  2. Commit the configuration.
    [edit]

    user@host# commit
  3. Reboot the device.

Results

From configuration mode, confirm your configuration by entering the show chassis command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

[edit]

user@host> show chassis fpc pic-status

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

Verification

Verifying the Configuration of IOC for Express Path

Purpose

Verify that the IOC was configured properly for Express Path.

Action

From operational mode, enter the show chassis fpc pic-status command.

Example: Configuring an SRX5K-MPC on an SRX5000 Line Device to Support Express Path

This example shows how to configure an SRX5K-MPC on an SRX5000 line device to support Express Path (formerly known as services offloading).

Requirements

This example uses the following hardware and software components:

  • One SRX5000 line device with an SRX5K-MPC

  • Junos OS Release 12.3X48 or later for SRX Series devices

Before you begin, understand Express Path overview..

No special configuration beyond device initialization is required before configuring this feature.

Overview

In this example, you configure the SRX5K-MPC on an SRX5000 line device to perform NP cache and Express Path.

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

To configure an SRX5K-MPC on an SRX5000 line device to perform Express Path:

  1. Set NP cache mode on the SRX5K-MPC on FPC 1 and FPC 2.
  2. Configure a policy to process the traffic that goes to the HTTP static ports.
  3. Enable Express Path in the security policy.
  4. Commit the configuration.
  5. Reboot the device.

Results

From configuration mode, confirm your configuration by entering the show chassis command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

For brevity, this show command output includes only the configuration that is relevant to this example. Any other configuration on the system has been replaced with ellipses (...).

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

Verification

Confirm that the configuration is working properly.

Verifying the Configuration of an SRX5K-MPC for Express Path

Purpose

Verify that the SRX5K-MPC was configured properly for Express Path.

Action

From operational mode, enter the show chassis fpc pic-status command.

Meaning

The output provides the status of PICs with Express Path enabled on them.

Example: Configuring SRX5K-MPC3-100G10G (IOC3) and SRX5K-MPC3-40G10G (IOC3) on an SRX5000 Line Device to Support Express Path

This example shows how to configure an SRX5K-MPC3-100G10G (IOC3) or an SRX5K-MPC3-40G10G (IOC3) on an SRX5000 line device to support Express Path (formerly known as services offloading).

Requirements

This example uses the following hardware and software components:

  • One SRX5000 line device with an SRX5K-MPC3-40G10G (IOC3)

  • Junos OS Release 15.1X49-D10 or later for SRX Series devices

Before you begin, understand Express Path overview..

No special configuration beyond device initialization is required before configuring this feature.

Overview

In this example, you configure an SRX5K-MPC3-40G10G (IOC3) on an SRX5000 line device to perform Express Path.

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

To configure an SRX5K-MPC3-40G10G (IOC3) on an SRX5000 line device to perform Express Path:

  1. Set the Express Path mode on the SRX5K-MPC3 on FPC 4 and FPC 5.
  2. Configure a policy to process the traffic that goes to the HTTP static ports.
  3. Enable Express Path in the security policy.
  4. Commit the configuration.
  5. Reboot the device.

Results

From configuration mode, confirm your configuration by entering the show chassis command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

For brevity, this show command output includes only the configuration that is relevant to this example. Any other configuration on the system has been replaced with ellipses (...).

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

Verification

Confirm that the configuration is working properly.

Verifying the Configuration of an SRX5K-MPC3 (IOC3) for Express Path

Purpose

Verify that the SRX5K-MPC3-40G10G (IOC3) was configured properly for Express Path.

Action

From operational mode, enter the show chassis fpc pic-status command.

Meaning

The output provides the status of PICs with Express Path enabled on them.

Example: Configuring Express Path on an SRX5000 Line Device with IOC3

This example shows how to configure Express Path (formerly known as services offloading) on an SRX5K-MPC3-100G10G (IOC3) or an SRX5K-MPC3-40G10G (IOC3) on an SRX5000 line device.

Express Path is a mechanism for processing fast-path packets in the network instead of in the Services Processing Unit (SPU). This method reduces the long packet-processing latency that arises when packets are forwarded from network processors to SPUs for processing and back to IOCs for transmission.

Starting in Junos OS Release 15.1X49-D40, the configuration is valid for IPv6 traffic, whereas before it was supported for IPv4 traffic only.

Requirements

This example uses the following hardware and software components:

  • One SRX5000 line device with an IOC3 card

  • Junos OS Release 15.1X49-D40 or later for SRX Series devices

Before you begin, understand the Express Path overview..

No special configuration beyond device initialization is required before configuring this feature.

Overview

In this example, you configure Express Path on IOC3 on an SRX5000 line device for IPv6 traffic.

You configure two interfaces on IOC3 card and assign IPv6 addresses to them. Then you enable flow-based processing for IPv6 traffic. Next, you set up zones and add interfaces to them. Then you provide communication between the two different zones by configuring a security policy to allow traffic between two zones. You also enable Express Path in security policies to specify whether the traffic qualifies for Express Path.

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

To configure an SRX5K-MPC3-40G10G (IOC3) on an SRX5000 line device to perform Express Path:

  1. Configure Ethernet interface and assign an IPv6 address to it.
  2. Enable flow-based processing for IPv6 traffic.
  3. Configure security zones and add interfaces and allow all system services and interfaces. Configure a security zone and specify the types of traffic and protocols that are allowed on interface et-2/1/0.0.
  4. Configure security zones and add interfaces and allow all system services and interfaces. Configure a security zone and specify the types of traffic and protocols that are allowed on interface et-2/3/0.0.
  5. Create a policy and specify the match criteria for that policy. The match criteria specifies that the device can allow traffic from any source, to any destination, and on any application. Enable Express Path in the security policy.Note

    You can specify the wildcard any-ipv6 for the source and destination address match criteria to include only IPv6 addresses. Specifying any option for the source and destination address match criteria to include both IPv4 and IPv6 addresses.

  6. Set the Express Path mode on IOC3.

Results

From configuration mode, confirm your configuration by entering the show chassis command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

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

Verification

Confirm that the configuration is working properly.

Verifying the Configuration of an SRX5K-MPC3 (IOC3) for Express Path

Purpose

Verify that the IOC3 was configured properly for Express Path.

Action

From operational mode, enter the show chassis fpc pic-status command.

Meaning

The output provides the status of PICs with Express Path enabled on them.

Verifying All Active Sessions on the Device

Purpose

Display information about all currently active Express Path security sessions on the device.

Action

From operational mode, enter the show security flow session services-offload command.

Meaning

The output provides the policy details for sessions on which Express Path was enabled.

Example: Configuring Low Latency

The low latency feature allows you to configure the mode of the network processor’s traffic manager (TM) on the egress path. If low latency is enabled, the network processor is initialized without the traffic manager, thus reducing the overall latency in the Express Path (formerly known as services offloading).

Note

Because all SRX Series CoS functions are supported by the traffic manager, CoS functions are not supported when low latency is enabled.

Low latency reduces the total NPC integrated with an existing IOC (NP-IOC) latency by 0.7 us. This latency reduction brings the NP-IOC card total latency to 8.7 us. The low-latency feature is supported for intra-NP-IOC card traffic only; it is not applicable to inter-NP traffic.

In the low-latency mode, the network processor does not have an egress buffer at the traffic manager. Packets are delivered directly to the system packet interface (SPI) for the field-programmable gate array (FPGA) to process.

Note

The low latency feature is only applicable to the NP-IOC card.

Requirements

Before you begin, understand Express Path overview..

This example uses the following software and hardware components:

  • Junos OS Release 12.1X44-D10

  • One SRX Series device

  • One Services Processing Card (SPC)

Overview

In this example, you configure the network processor for low latency mode.

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

To enable low-latency mode:

  1. Enable the Express Path mode on the NP-IOC.
    [edit]

    user@host# set chassis fpc 7 pic 0 services-offload low-latency
  2. Commit the configuration.
    [edit]

    user@host# commit
  3. Reboot the device.

Results

From configuration mode, confirm your configuration by entering the show configuration chassis command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

[edit]

user@host> show configuration chassis

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

Verification

Verifying Low Latency Configuration

Purpose

Verify that low-latency was enabled.

Action

From operational mode, enter the show chassis fpc pic-status command.

Managing Packet Fragmentation in IPsec VPN Networks

Packet fragmentation degrades system performance in IPsec VPN networks. The SRX Series packet fragmentation counters feature allows you to monitor the amount of packet fragmentation incurred in processing traffic for IPsec tunnels on your device and throughout your network. It counts fragmented packets that can occur before tunnel encapsulation and afterward for individual tunnels. It also counts overall the number of fragmented packets for tunnel sessions on a Services Processing Unit (SPU).

To understand the amount of packet fragmentation in your network in order to prevent it from occurring, it is helpful to be able to measure it. After you tune your system for improvement, it is useful to be able to verify the results.

The fragmentation counters feature provides output through the show security flow commands that you can use to display fragmentation counter statistics. You can display fragmented packet numbers collectively for individual IPsec tunnels. You can also obtain a summary of the number of fragmented packets based on the SPU.

You can use the fragmentation information provided through show commands as input to your iterative tuning process to decrease the likelihood of fragmentation occurrence. Use of this feature allows you to achieve optimum SRX Series performance otherwise limited by packet fragmentation.

Fragmentation Counters Feature Overview

Datagrams are fragmented when a packet is larger than the maximum transmission unit (MTU) size established for a device’s egress interface. The egress interface’s MTU size determines the size of the packets sent to the receiving device. A datagram could also be fragmented into smaller packets to transit a link in the datapath because the packet is larger than the amount of data that the receiving device can accept or larger than the MTU of any link in the datapath. In any case, the packet header of the original datagram that was broken into fragments is added to each of the fragmented packets, in addition to the parts of the payload that the fragment carries.

It is important to understand the degree and kinds of fragmentation occurring on your device in order to tune your system to avoid it. The Junos OS for SRX Series fragmentation counters feature counts packet fragments for IPsec tunnels that can occur before and after a packet is encapsulated with an IPsec encryption header.

The fragmentation counters feature takes into account the following kinds of packet fragmentation:

Pre-fragmentationSelf-generated packet fragmentation that occurs prior to encapsulation
Post-fragmentationPackets that are received by the SRX Series device and packets that are fragmented after encryption.

For an individual tunnel, a counter is increased whenever a fragment is encountered. Fragments that occur before packet encapsulation are counted separately from fragments that occur because of encapsulation. When a counter is increased for an individual tunnel, the SPU fragmentation counter is also increased.

Understanding Fragmentation and MTU and MSS Sizes

Packet fragmentation can negatively impact performance of the entire IPsec VPN, and it must be avoided for that reason. Fragmentation is likely to occur when a datagram approximates the MTU size set for the egress interface of the sending device. When IPsec VPN datagrams are fragmented, the resulting fragment packets are encapsulated with IPsec ESP or AH headers in addition to the datagram’s original TCP header. Fragmentation negatively impacts the IPsec peers at either end of the IPsec VPN tunnel. Fragmentation—breaking a datagram into smaller packets to be reassembled later—incurs CPU and memory overhead on both the sending peer and the receiving peer. The impact on the sending peer is minimal. It must break down the datagram. The impact on the receiving peer is far greater because it must allocate memory for incoming packets and reassemble them into the complete datagram before it can decrypt the cohesive datagram.

The size of a packet to be transmitted to the receiving peer is based on two values: the MTU size and maximum segment size (MSS). The MTU size established for the egress interface determines the size of the datagram that the sending peer transmits to the receiving peer. Although a larger MTU size can result in greater efficiency, it can have a negative impact, resulting in packet fragmentation downstream.

The MSS of a device specifies the maximum amount of information that the device can accept in a single IP datagram. In IPsec VPNs, each peer compares its outgoing interface MTU size with its own MSS buffer size. It must send the smaller of the two values to the receiving peer as its MSS. During the three-way handshake negotiation between the two IPsec VPN peers, the smaller MSS value is selected to be used in sending packets. The MSS value is sent as a TCP header option in TCP SYN segments.

Using Fragmentation Counter Statistics to Tune Your System

There are a number of methods that you can use to limit the degree of fragmentation that can occur when IPsec VPN tunnels are used. Regardless of the method that you use, it is helpful to be able to observe and measure the volume of fragmentation that is being transmitted before and after you iteratively tune your network. The SRX Series fragmentation counters feature provides that information in the following show commands output:

  • To see fragmentation information for individual tunnels, use the show security flow session tunnel extensive command.

  • To see overall fragmentation information based on an SPU, use the show security flow session tunnel summary command.

  • To see statistics on the number of pre-fragments and post-fragments on an SPU, use the show security flow statistics command.

Here are two of the basic approaches that you can take to manage fragmentation between the two IPsec VPN peers:

  1. Manipulate the MSS of the sending peer to establish the appropriate MTU size for its egress interface.

    Note

    The sending peer device should not send packets that are larger than the receiving peer device can accept, as determined by the receiving peer’s MSS value.

    For details on changing the MSS setting on the sending peer’s device to effect a smaller MTU size on that device.

    Use the fragmentation counters statistics displayed by the related show commands to iteratively tune the MSS value on the sending peer until fragmentation between the peers is eliminated.

    To get the fragmentation statistics result of your tuning, you must renegotiate the MSS value with the receiving peer.

    Before you renegotiate with the receiving peer, you must clear the show commands to reset their counters. If further tuning is required, you must clear the show commands before changing the MSS value and renegotiating again with the receiving peer.

    To clear the fragmentation counters for the show security flow statistics command, use the following command:

    To clear the fragmentation counters for the show security flow session tunnel extensive and the show security flow session tunnel summary commands, you must deactivate the IPsec tunnel and then reactivate it.

    Use the following statements to deactivate the IPsec VPN:

    Use the following statements to reactivate the IPsec VPN to enact the three-way handshake with the peer device in which the MSS values of the peers are exchanged:

  2. Use the ping command

    You could use the ICMP ping command to determine the correct packet size to use in establishing the appropriate MTU size. To find the proper MTU size, you must send the ping repeatedly to the receiving peer until no fragmentation message is returned.

    You could start at 1450 and if you receive a fragmentation message, you could decrease the size by 10 each time you issue the ping command. If you do not get a fragmented packet reply message, you could incrementally increase the MTU size.

    Although you can control fragmentation between the two IPsec VPN endpoint peers, it can happen that a link in the datapath between them cannot accept a packet because its MSS value is too small or a link could have a smaller MTU size than the size of the packet that it received and must break it down the before transmitting it. Technologies are available such as path maximum transmission unit (PMTU) that can be used to dynamically determine the MTU size to avoid fragmentation along the datapath.

Release History Table
Release
Description
Starting with Junos OS Release 15.1X49-D80, two new system log messages have been added to indicate memory-related problems on the interfaces to the DDR3 memory.
Starting with Junos OS Release 15.1X49-D60 and Junos OS Release 17.3R1, SRX5400, SRX5600, and SRX5800 devices with the SRX5K-MPC (IOC2), SRX5K-MPC3-100G10G (IOC3), and SRX5K-MPC3-40G10G (IOC3) support Express Path (formerly known as services offloading) for ALG traffic.
Starting in Junos OS 15.1X49-D40 and Junos OS Release 17.3R1, IPv6 is supported.
Starting with Junos OS Release 12.3X48-D10 and Junos OS Release 17.3R1, a license is no longer required to enable Express Path functionality.
Starting with Junos OS Release 12.3X48-D10 and Junos OS Release 17.3R1, the Express Path license is no longer required to enable the Express Path functionality.