Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Architecture

This topic provides information about SRX4700 Firewall architecture, illustration, key components, and packet flow overview.

Overview

The SRX4700 Firewall runs Junos OS, a modular OS that powers its high-performance security services, including next-generation firewalling, zero trust capabilities, and integration with EVPN-VXLAN fabrics. It supports centralized management using the Juniper Security Director Cloud, which provides a unified policy framework for consistent security across environments, secure zero-touch provisioning (SZTP), and security features such as NAT and IPsec VPN.

Figure 1: SRX4700 Software Architecture SRX4700 Software Architecture

The SRX4700 Firewall uses flow‑based processing with Trio ASICs to deliver high‑performance security. It integrates Network Processing Units (NPUs) and Services Processing Units (SPUs) in a distributed architecture, enabling scalable packet processing with a throughput of up to 1.4 Tbps.

The SRX4700 Firewall employs a distributed architecture that separates the control plane, security processing, and high-speed data forwarding. This design enables most traffic to be processed in hardware fast paths transferring packets to the security engines or the control plane only when required for inspection or management.

The core software components of the SRX4700 Firewall include:

  • Junos OS flow‑based processing—Provides stateful firewall, NAT, and security services. NPUs perform initial packet parsing and session lookup. If no existing session is found, packets are forwarded to SPUs for deeper inspection and policy processing.

  • Express Path—Express Path (formerly services offloading) processes fast-path packets in the network processor instead of the SPU for lower latency and higher throughput. Reduces single‑flow latency by offloading established flows to NPUs after first‑packet processing.

Packet Flow Overview

The SRX4700 follows a packet flow model for first‑packet and fast‑path processing.

First‑Packet Processing (No Existing Session)

This flow describes how packets are handled when an incoming packet does not match any session in the NPU session table, triggering session setup for flow-based processing.

Figure 2: First‑Packet Processing First‑Packet Processing

Logical Flow: Ingress IOC (NPU) → SPU selection → SPU session creation → Fast path → Egress IOC → Transmit

The incoming packet is received on the ingress IOC NPU, where headers are parsed and the 5‑tuple is extracted. Initial NPU processing includes DoS screens, packet filters, CoS, policers or shapers, crypto offload (if applicable), and fragmentation handling (reassembly). A session lookup is then performed; if no matching session is found, the packet is sent to the slow path.

If no session exists, the NPU uses a 5‑tuple hash to deterministically select an SPU core (no central point). The SPU creates the session, evaluates security policy, applies NAT and services, and determines Express Path eligibility.

The session is created on ingress and egress NPUs and cached for fast forwarding. Subsequent packets are forwarded using cached session data.

Egress NPU performs final processing (TCP check, TTL decrement, and L2 rewrite) and transmits the packet.

Note:

SRX4700 Firewall architecture difference:

Unlike SRX5000 line of Firewalls, the SRX4700 does not use a Central Point (CP) SPU. Instead, the ingress NPU directly selects the target SPU core using a 5‑tuple hash and a local SPU weight table, removing the CP processing hop. After the SPU creates the session, it is programmed into the flow tables on both the ingress and egress NPUs.

Fast-Path Packet Processing (Session Hit)

This flow describes how packets are handled when an existing session is found and traffic can remain on the fast path and bypass security policy re‑evaluation.

Figure 3: Fast-Path Packet Processing Fast-Path Packet Processing

Logical Flow: Ingress NPU (IOC)→Session hit→SPU (L3–L7 fast path)→Egress NPU (IOC)→Packet out

In a distributed data plane, session‑hit traffic is processed on a fast path that splits work between ingress NPUs and stateful SPUs. The ingress NPU parses packet headers, applies early screening and QoS, and performs a session lookup. When a session hit is found and qualifies for fast‑path processing, the packet is forwarded directly to the SPU core that owns the session.

This forwarding uses a cached session‑to‑SPU core mapping stored in the NPU session entry, eliminating additional hashing or centralized coordination. There is no central point in the datapath. The SPU applies all stateful L3 through L7 services including NAT, ALG, IDP, AppFW, and Content Security using the prebuilt session state. The security policy is not re‑evaluated.

After processing, the packet is returned to the egress NPU for transmission. The SPU core remains pinned to the session for all subsequent packets, ensuring consistent and efficient handling.

Benefits:

  • No policy re-evaluation for session-hit traffic.
  • Clear separation of NPU (packet handling) and SPU (stateful services).
  • Cached SPU mapping avoids unnecessary hashing.
  • Optimized for data-center and high-throughput deployments.

Express Path Packet Processing (IOC‑Based)

Express path enables high‑throughput packet forwarding by allowing eligible sessions to be processed entirely on the IOC NPUs, bypassing the SPU, with minimal per‑packet checks and cached forwarding information.

Figure 4: Express Path Packet Processing (IOC‑based) Express Path Packet Processing (IOC‑based)

Logical Flow: Ingress NPU (IOC) → Express Path Match → IOC NPU Processing → Egress NPU → Packet Out

When a packet matches an existing Express Path session, processing is handled entirely on the IOC NPU, bypassing the SPU.

When a packet arrives at the IOC:

  • Packet headers are parsed and a 5‑tuple is extracted.

  • DDoS screens, packet filters, CoS policers, and shapers are applied.

  • Crypto offload, fragmentation, and reassembly occur if required.

The NPU performs per‑packet validation, including TCP sequence checks and TTL decrement. The session state cached during initial setup, such as NAT offsets and the egress interface, is reused. The Layer 2 header is rewritten, per‑session counters are updated, and the packet is forwarded directly out of the egress IOC after shaping and scheduling.

Express Path is not used when traffic requires any of the following:

  • IDP or AppID deep inspection
  • ALG processing
  • Traffic shaping configured on SPU
  • Firewall filters that redirect traffic to a virtual router (VR)

In these scenarios, traffic is processed by the SPU (slow path).