2012 srx-architecture-pdf

SRX HIGH-END ARCHITECTURE

Bill Pfeifer

Product Line Engineer – Security

January 2012

2 Copyright © 2010 Juniper Networks, Inc. www.juniper.net

JUNIPER CONFIDENTIAL – DO NOT DISTRIBUTE

LEGAL STATEMENT

This statement of product direction sets forth Juniper Networks’ current intention and is subject to change at any time without notice. No purchases are contingent upon Juniper Networks delivering any feature or functionality depicted on this statement.

This presentation contains proprietary roadmap and architecture information and is covered by NDA



WHY DO I NEED TO KNOW THIS?

One of the key differentiators of the SRX was (and still is) its

architecture. It gives the box great flexibility and scalability;

unfortunately that comes at a cost of complexity.

If you have a solid understanding of how the SRX works, then

you’ll be better able to position it in competitive situations.

Simplicity, flexibility, and scalability – pick two.



AGENDA

Chassis

Cards and Packet Flow

Chip Functions

HA

VPN

Screens

Services Offload



Control Panel

Air intake

Lower fan tray

Upper fan tray

Services Processing

Card

4 x 10GbE I/O Card

40 x GbE I/O Card

16 RU Modular chassis

– Vertical design – 12 expansion slots

– Modules for flexible I/O and service processing – Junos software

Massive Scale – Up to 350,000 new & sustained

connections per second (CPS) – Up to 12.5/14* million sessions

High performance – Up to 120 Gbps firewall

– Up to 30 Gbps IPS – Up to 30 Gbps IPSec VPN

High availability – Redundant management modules

– Redundant switching fabrics – Redundant fans & power supplies

– Modular Junos Software

*14M session can impact routing table and GPRS capabiliy

Management module

Switch Control Boards (SCBs)

Expansion slots (fits any module)

SRX5800 Front View

SRX5800 Rear View

Power supplies

FRU

SRX5800: FRONT AND REAR VIEW



8 RU Modular chassis

– Horizontal design – 6 expansion slots

– Modules for flexible I/O and service processing – Junos software

Massive scale – Up to 350,000 new & sustained

connections per second (CPS) – Up to 9 million sessions


– Up to 15 Gbps IPS – Up to 15 Gbps IPSec VPN

High availability – Redundant management

modules – Redundant switching fabrics

– Redundant fans & power supplies


Expansion slot (fits any module)

Control Panel

Upper fan tray

Services Processing

Card

Switch Control Boards (SCBs)

40 x GbE IOC

Management Module

Power supplies

FRU

SRX5600 Front View

SRX5600 Rear View

SRX5600: FRONT AND REAR VIEWS



5 RU

Modular chassis – 12 expansion slots

(6 front and 6 rear)

– Compact form factor modules for I/O and service processing

– Dual, hot swappable management modules

– Junos Software

Massive scale – Up to 175,000 new, sustained

connections per second (CPS)

– Up to 2.25 million sessions

– With Extreme license, up to 6M sessions and 300k CPS


– Up to 10 Gbps IPS

– Up to 10 Gbps IPSec VPN

High availability – Redundant power and fans

– Redundant management


Routing Engine

Expansion slot (IOC/SPC)

Power supplies FRU

12 on-board GigE ports USB

Redundant Routing Engine (future) or SCM

Redundant power supplies

(optional)

16 x 10/100/1000 I/O card

Fan tray

16 x GbE SFP I/O

card

Expansion slot (SPC)

SRX3600 Front View

SRX3600 Rear View

2 x 10 GigE I/O card

Switch Fabric Board (SFB)

Fan tray door

Expansion slot (SPC/NPC)

Front slot guide

Rear slot guide


Note: Power cords (“straight” C19 plug) not included with BASE system. Right-Angled power cords interfere with cards but are usable.



3 RU


(4 front and 3 rear)

– Compact form factor modules for I/O and service processing

– Dual, hot swappable management modules

– Junos Software



– Up to 2.25 million sessions





– Redundant management


SRX3400 Front View

SRX3400 Rear View

Routing Engine

Expansion Slot (IOC/SPC)

Power supply FRU

12 on-board GbE ports USB

Expansion Slot (SPC/NPC)

Redundant power supply

(optional)

16 x 10/100/1000 I/O card

Fan tray

16 x GbE SFP I/O

card

Expansion Slot (SPC/NPC)

Redundant Routing Engine (future) or SCM

2 x 10 GigE I/O card

Front slot guide

Rear slot guide

Fan tray door

Switch Fabric Board (SFB)


Note: Power cords (“straight” C19 plug) not included with BASE system. Right-Angled power cords interfere with cards but are usable.



3 RU


Compact form factor modules shared with SRX3000

– Junos Software



– Up to .5 million sessions [at FRS]





– Chassis Clustering


– Shared HA-control ports

– High availability

SRX3000 technology

– Common sparing possible

Management Module (RE)

Expansion Slot

(IOC)

12 on-board ports:

1400GE: 6+4+2 GE

1400XGE: 3 XGE plus 6+1+2 GE

Power supply

FRU

Redundant

power supply

(optional)

Fan tray

(rear)

Expansion Slots

(NSPC or SPC+NPC)

SRX1400 FRONT VIEW

Slot

guide

Note: Region-appropriate Power Cord (“straight” C13 plug) is included with BASE system but not with spare (redundant) power supplies.



SRX HIGH END: KEY DIFFERENCES

SRX5k SRX3k SRX1k

Fabric? Yes Yes No

Card Options SPC, IOC SPC, IOC, NPC NSPC (or NPC/SPC),

IOC

Slots 12/6 12/7 3

10G optics XFP XFP SFP+ (onboard), XFP

(IOC)

HA Ctrl Ports On SPC On SFB Revenue Ports

Redundant Ctrl Link Requires second RE Requires CRM Supported

Dual Data Link Supported Supported Supported



• 2-3 Switch Control Boards (SCBs)

• Non-blocking any-to-any connectivity • ~2x speedup for

performance • SCBs fully redundant

• Graceful degradation • Packet Order maintained

• Sequence ID used on ingress

• Reorder buffer resequences in SPC

• QoS Maintained • Strict priority queuing

on ingress IOC • Parallel virtual paths for

high and low priority packets

• 4 active logical fabric planes

• Every IOC/SPC connects to every logical fabric plane

• Failover time: ~1s

SWITCH FABRIC ARCHITECTURE

SCBs

Active

Standby



AGENDA

Chassis


Chip Functions

HA

VPN

Screens

Services Offload



I NP

I

I

I

5k IOC

(40x1G and 4x10G)

Fa

bri

c

FPGA

FPGA

5k FlexIOC

(pluggable cards for 16x1G or

4x10G)

1k/3k IOC

IOC

1k/3k NPC

PHY

PHY NP

PHY NP

PHY NP

SWI NP

SWI NP

Fa

bric

Fa

bric

Fa

bric

FPGA NP FPGA

FPGA SWI

Fa

bric

Fa

bric

NPC actually has a single FPGA used for both ingress and egress; this deck

shows 2 for clarity of traffic flow.



SPC

1k/3k SPC

FPGA SPU

5k SPC

I SPU

I SPU

Fa

bri

c

Fa

bric

Fa

bric



PACKET FLOW: FIRST PACKET OF NEW FLOW

I NP

I NP

I NP

I NP

IOC

SPC #1

I CP

I SPU

SPC #N

I SPU

I SPU

1. Packet Received by NP

NP flow lookup, no match

2. NP send packet to CP

3. CP chooses SPU, forwards packet

SPU does session setup

4. Packet forwarded out egress port

Fa

bri

c



PACKET FLOW: SESSION SETUP MESSAGES

I NP

I NP

I NP

I NP

IOC

SPC #1

I CP

I SPU

SPC #N

I SPU

I SPU

Fa

bri

c

1. SPU sends insert session to CP

2. SPU sends insert session to ingress NP

3. SPU sends insert session to egress NP



PACKET FLOW: FAST PATH

I NP

I NP

I NP

I NP

IOC

SPC #1

I CP

I SPU

SPC #N

I SPU

I SPU

Fa

bri

c


NP flow lookup, match

2. NP send packet to SPU

SPU does fast path processing

3. Packet forwarded to egress NP

4. Packet egresses card



CP

SPU

FPGA

SPU FPGA

Fa

bri

c –

IO

C d

om

ain

Fa

bri

c –

SP

C d

om

ain

FPGA NP FPGA

FPGA NP FPGA

FPGA SWI

FPGA SWI



SPC #1

IOC #Y NPC #S

IOC #X NPC #R

SPC #N

3. CP chooses SPU, forwards packet SPU does session setup

4. Packet forwarded out egress port via NPC for queuing

2. NP sends packet to CP






2. SPU sends insert session to ingress NP

3. SPU sends insert session to egress NP

CP

SPU

FPGA

SPU FPGA

Fa

bri

c –

IO

C d

om

ain

Fa

bri

c –

SP

C d

om

ain

FPGA NP FPGA

FPGA NP FPGA

FPGA SWI

FPGA SWI

SPC #1

IOC #Y NPC #S

IOC #X NPC #R

SPC #N



CP

SPU

FPGA

SPU FPGA

Fa

bri

c –

IO

C d

om

ain

Fa

bri

c –

SP

C d

om

ain

FPGA NP FPGA

FPGA NP FPGA

FPGA SWI

FPGA SWI

SPC #1

IOC #Y NPC #S

IOC #X NPC #R

SPC #N


1. Packet Received by NP NP flow lookup, match

2. NP send packet to SPU - SPU does fast path processing







3. CP chooses SPU, forwards packet SPU does session setup

4. Packet forwarded out egress port via NPC for queuing

2. NP sends packet to CP


CP

SPU

FPGA FPGA NP FPGA FPGA SWI

FPGA SWI

NSPC

IOC

SYSIO





2. SPU sends insert session to ingress/egress NP

FPGA NP FPGA FPGA SWI

FPGA SWI

NSPC

IOC

SYSIO

FPGA

CP

SPU




1. Packet Received by NP NP flow lookup, match

2. NP send packet to SPU - SPU does fast path processing



CP

SPU

FPGA FPGA NP FPGA FPGA SWI

FPGA SWI

NSPC

IOC

SYSIO



CP

SPU

FPGA

MORE ABOUT CENTRAL POINT

We’ve seen dedicated-mode and combo-mode in earlier slides; what’s that all about?

Combo-mode: shares the capacity of an SPU between CP and flow on a chassis with a limited # of SPUs.

‘Small’ CP:

3k: 1-2 SPCs installed 3/8 of SPU

‘Medium’ CP:

3k: 3+ SPCs / 5k: 1-2 SPCs 1/2 of SPU

‘Large’ CP:

3k: Extreme License / 5k: 3+ SPCs 1 full SPU is taken by CP

I CP

I SPU



CP

SPU

FPGA

3K EXTREME LICENSE

Extreme License on SRX3k converts CP to Full/Large (100% of one SPU – 3k only).

- Increases session capacity to 6M on 3600 and 3M on 3400

- Boosts CPS, but at a cost of some PPS/services capacity (you’re taking the full SPU, so it’s not available for packet processing or services)

2M sessions per NPC, 1M sessions per SPC, so requires 3 NPC, 6 SPC in 3600 or 2 NPC, 3 SPC in 3400 for max capacity

CP FPGA

Similar function available in SRX5k (no license required); boosts session capacity to 14M but reduces route capacity to 100k routes and disables GPRS/GTP.

Note that this is a session increase, not a PPS increase; it alters memory allocation, not CP size (i.e., not processor allocation). Requires reboot, since it reallocates memory.

‘set security forwarding-process application-services maximize-cp-sessions’



AGENDA

Chassis


Chip Functions

HA

VPN

Screens

Services Offload



SPU

I

FPGA SPU

I Fa

bric

LBT POT CTRL

SPU is a eight-core processor, running 4 threads per core

24 flow threads, 4 control plane threads, 4 infrastructure threads

SPU provides most of the services offered by the SRX, including:

Advanced Routing ALG

Stateful Firewalling DoS/DDoS

IPS VPN

NAT Some screens



SPU (CONT’D)

I

FPGA SPU

I Fa

bric

Each SPU can process:

40-50k connections per second (CPS)

1.1M packets per second (PPS)

10Gbps total throughput (large packet)

5Gbps total throughput (IMIX traffic)

1M sessions

1M NAT sessions

Each flow is tied to a single SPU, so max throughput for a single flow is limited to 1 SPU’s worth of throughput (10Gbps for large-packet flows, less for smaller-packet flows).

Performance

impact

No performance

impact



NPU The NPU is responsible for packet-handling tasks such as:

• Session lookup and caching

• Most Screen functions

• QoS

NPU Capacity:

SRX5k standard IOC: 1M sessions / 2M wings*

SRX5k FlexIOC: 2M sessions / 4M wings*

(FlexIOC has half the NPUs of standard IOC, but same memory, so

effectively double the memory per NPU of standard IOCs)

SRX1k/3k NPC: 2M sessions / 4M wings*

Note that a wing is half a session – a session is bidirectional (outbound and return traffic) and a wing in unidirectional (outbound OR return traffic).

*In 11.4, we get a 50% increase in NPU session counts for all NPUs.



NPU (CONT’D)

When traffic arrives on an interface, the NPU checks its session cache and forwards the packet to either the CP for session setup or to the appropriate SPU for session handling.

Traffic returning from an SPU has an internal header, and does not require a session-cache lookup.

Because of this, each session will require 2 wings – one on the NPU receiving inbound traffic from the network, the other on the NPU receiving return traffic from the network. If the both source and destination IPs are on the same NPU, then both wings (a full session) will be installed on that NPU.

For maximum session scale per port, make sure your sessions run across 2 NPUs (inbound and outbound).

FPGA NP FPGA FPGA NP FPGA Source Device

DestinationDevice

Se

rvic

es

an

d

Ma

gic

al S

RX

H

ap

pin

es

s

Source-to-Destination wing for inbound traffic

Destination-to-Source wing for return traffic



NPU (WING SETUP)

Source Device


FPGA SPU

I


DestinationDevice

Source-to-Destination wing installed here

Destination-to-Source wing installed here



NPU (LINK AGGREGATION, SLIDE 1/2)

Link aggregation in the SRX uses per-flow load balancing, based on a source/destination/port hash to determine the outbound port. Sessions are sticky, and wings get installed to NPUs as part of normal operation.



Per-flow load balancing



NPU (LINK AGGREGATION, SLIDE 2/2)

If the device on the other side of the link aggregation group is using per-packet load balancing rather than per-flow, packets from each flow will be sprayed across all the NPUs in the link aggregation bundle.

Wings from each flow will be installed on each NPU, and overall max session capacity (as well as CP utilization) will suffer as a result.

Note that this isn’t a problem if you have relatively low session counts!



Caution! Possible per-packet load balancing

(not common)



NPU (PPS HANDLING)

One NPU can handle 10Gbps of traffic at full duplex (10G ingress, 10G egress).

In addition to just passing traffic, there is overhead associated with processing a packet (sanity checking, policing, etc), so there is also a packet-per-second (PPS) limitation.

A single NPU can ingress roughly 4.5M PPS. Because egress traffic requires less processing, an NPU can egress roughly 14M PPS.

10Gbps of traffic @ 64 byte packets equals roughly 16M PPS

I NP

I

I

I

PHY

PHY NP

PHY NP

PHY NP

~4.5M PPS ingress

~4.5M PPS ingress

~4.5M PPS ingress

~14M PPS engress

Throughput = packet size * packets per second (roughly)

1Gb = 1,073,741,842b (1024 b/Kb, 1024 Kb/Mb, 1024 Mb/Gb)

Roughly 20B overhead (12B inter-packet gap, 4B preamble, 4B CRC)

How many 64B packets/sec in 10Gbps??

64B + 20B = 84B * 8b/B = 672b

10Gbps * 1,073,741,842 b/GB / 672b = 15,978,301 PPS

~ 16M PPS



NPU (SESSION CACHE FULL)

Source Device sends traffic


FPGA CP

I

1. Source device sends inbound traffic.

2. NP checks cache; no match is found. Packet is forwarded to CP for handling.

3. CP forwards packet to SPU for processing, packet is processed and sent to egress port.

4. SPU sends session setup messages to CP, ingress NPU, egress NPU. Ingress NPU cache is full, so message is dropped.

5. More inbound traffic is received. Ingress NPU checks cache; no match is found. Packet is forwarded to CP for handling.

6. CP checks its session cache, locates session, forwards packet to appropriate SPU for processing.

Traffic continues, but with additional latency and with additional load on CP. At some point, CP will become overtaxed (~1.2M PPS).

FPGA SPU

I

1

2

3

4

5

6



NPU (NPU BUNDLING)

NPU bundling (5k only) allows you to achieve higher session counts than normally possible on a single port.

One NPU is configured as a Master, and 2 or more NPUs are configured as Helper NPUs; the Master will balance traffic across the Helper NPUs.

This gives the Master access to the session cache of multiple Helper NPUs.

This is mostly just relevant to services providers and specific, niche applications. If you need to know more, contact your Juniper SE for further information.

I NP

I

I

I

PHY

PHY NP

PHY NP

PHY NP

Fa

bric

Master

NPU

Helper

NPUs



NPU (3K IOC ASSIGNMENT)

SRX5k has NPU on IOC, and ports (specifically, PHY chips) are statically mapped to an NPU.

SRX3k, the NPU is modular. IOCs are mapped to NPUs at boot time automatically.

More than one IOC can map to a particular NPU (though only one NPU can map to an IOC – NPU bundling not supported on the 3k).

If you have more IOCs than NPCs, you may need to control that mapping.

To manually map IOCs to NPUs:


FPGA SWI


‘set chassis ioc-npc-connectivity ioc <slot #> npc <slot#>’

To view the current mappings:

‘show chassis ioc-npc-connectivity’



NPU (3K NPU SLOTS)

FPGA NP FPGA

Why do NPUs have to plug into the back right side of the 3k because those slots have dual backplane connections.

NPUs are capable of 10Gbps bidirectional (10G in, 10G out).

FPGA NP FPGA

10G

10G

FPGA NP

10G

10G

There is actually only one FPGA on the NPC; the diagrams typically show two to clarify that the card has dual backplane connections to handle two 10G flows THROUGH the card.



I NP

I

I

I

5k IOC

Fa

bri

c

FPGA

FPGA

5k FlexIOC

1k/3k IOC

IOC (PORT MIRRORING)

1k/3k NPC

PHY

PHY NP

PHY NP

PHY NP

SWI NP

SWI NP

Fa

bric

Fa

bric

Fa

bric

FPGA NP FPGA

FPGA SWI

Fa

bric

Fa

bric

Broadcom switches that support port mirroring.

5k IOC PHY chip doesn’t support port mirroring.



IOC (INGRESS POLICERS)

SRX 3k and SRX5k FlexIOC: Only simple filters can be used for ingress policers. Policing is done on the broadcom switching chip (SWI).

SRX 5k Standard IOC: The 4x10Gbps card and 40x1Gbps card support ingress policing on the I-chip, and uses the standard Junos policing methods.

A simple filter is a subset of a firewall filter with the following limitations:

- Only the 5 tuple criteria can be matched (source-address, source-port, destination-address, destination-port, protocol)

- Non-contiguous mask are not supported

- Only 1 source-address and destination-address prefix are allowed for each filter term.



AGENDA

Chassis


Chip Functions

HA

VPN

Screens

Services Offload



HA - FAIL CHASSIS VS. CONTROL PLANE VS. FORWARDING PLANE

Complete chassis failure

CTRL

Data

CTRL

Data X

Control-plane failure (bad RE, etc)

CTRL

Data

X

Data-plane failure (port down, etc)

CTRL

Data X



HA – PREEMPT ON DATA PLANE ONLY

HA failover (reboot chassis, hardware

failure, etc)

CTRL

Data

CTRL

Data X

Primary chassis recovers; data plane moves back to primary. Control plane

does not allow preemption, so will remain on secondary chassis.

CTRL

Data

HA pair with preempt enabled to keep data plane traffic on the primary chassis

whenever possible.



HA – ACTIVE/ACTIVE

Active/Active is really just more than one instance of Active/Passive

CTRL

Data1

CTRL

X

Data2

Data1

Data2

In case of failure, both (or all, if more than 2 instances) redundancy groups will move to the active chassis.



HA – INTRA-CHASSIS REDUNDANCY – 5K

Second RE in a chassis enables the backup control link and will keep the chassis online in case of primary RE failure in an HA cluster.

RE

R

E

It does NOT, however, act as a backup RE. Only one RE per chassis is supported at this time.

RE

R

E

X = RE

R

E X




SCM in a chassis enables the backup control link and will keep the chassis online in case of RE failure in an HA cluster.

It does NOT, however, act as a backup RE. Only one RE per chassis is supported at this time.

RE SCM

RE SCM X



RE


Backup control link is enabled by default. Control links are established using revenue ports.

There is no backup option for the RE, so in case of RE failure the chassis will be disabled.

RE

X



AGENDA

Chassis


Chip Functions

HA

VPN

Screens

Services Offload



VPN

Inbound tunnel traffic hits CP, gets assigned to an SPU based on a hash of interface ID and 5-tuple

SPU decrypts the connection

Could have many flows within that tunnel, so each new flow goes to CP and gets assigned to an SPU (normal flow setup, except that it comes from an SPU rather than an NPU)

“Forwarding Session” is created on SPU that hosts the VPN for each session inside the tunnel. One wing is all zeros, the other wing contains information on the SPU that owns the session (per CP’s load balancing). Inbound traffic is then forwarded to the assigned SPU via the forwarding session.

If CP assigns the flow to the same SPU as the VPN is anchored to, no forwarding session is created.

Each SPU can handle roughly 2.5Gbps of encryption/decryption



VPN

15k tunnels per SRX5k

7.5k tunnels per SRX3k

5k tunnels per SRX1400 (PLM is confirming)

5k IPSec tunnels per SPU

1 SPU per SPC on 3k, 2 SPU per SPC on 5k (not counting CP)



AGENDA

Chassis


Chip Functions

HA

VPN

Screens

Services Offload



•block-frag

•fin-no-ack

•icmp-fragment

•icmp-id

•icmp-large

•ip-bad-option

•ip-filter-src

•ip-loose-src-route

•ip-record-route

•ip-security-opt

•ip-stream-opt

•ip-strict-src-route

•ip-timestamp-opt

•land

•ping-death

•syn-fin

MAJOR FUNCTIONS: INGRESS NPU

•Flow lookup

•Screens:

1k/3k NPC

Fa

bric

FPGA NP FPGA

Fa

bric

•syn-frag

•tcp-no-flag,

•unknown-protocol

•winnuke

•icmp-flood

•udp-flood

•syn-flood-destination-threshold

•syn-flood-source-threshold



•limit-session

•port-scan

•ip-sweep

•syn-flood (syn

cookie, syn proxy)

MAJOR FUNCTIONS: CP

•Flow load balancing

•Screens:

CP FPGA



•teardrop

•ip-spoofing

•syn-ack-ack-proxy

•syn flood (syn

cookie, syn proxy)

MAJOR FUNCTIONS: SPU

•Services

•Screens:

SPU FPGA



•QoS

•Queuing

•Shaping

MAJOR FUNCTIONS: EGRESS NPU

1k/3k NPC

Fa

bric

FPGA NP FPGA

Fa

bric



AGENDA

Chassis


Chip Functions

HA

VPN

Screens

Services Offload (formerly Low-Latency Firewall or LLF)



WHAT IS SERVICES OFFLOAD?

Originally called ‘Low Latency Firewall’ or ‘LLF’

Initial release targeted for trading environments in financial networks

Allows both latency-sensitive and normal traffic to be mixed on the

same platform

First path handled in SPC, fast path offloaded to the NP

Supports FW, NAT, NPU screens, and QoS

Available only on high-end SRX

Licensed as a software feature (but probably at zero cost)

General availability: Junos 11.4



SERVICES OFFLOAD – HOW IT WORKS

Session setup handled by CP and SPU (regular packet flow)

When configured with ‘services offload’, SPU will push policy to NPU, and further processing is handled directly by NPU

In 11.4, traffic has to stay on the same NPU

No support for services that require an SPU

LAG

Fragmented packets

IPS

Inter-LSYS traffic

Etc.

I NP

I

I

I

PHY

PHY NP

PHY NP

PHY NP



THEORETICAL DATASHEET WITH LLF

SRX5600 SRX5800

Feature Current datasheet

Balanced LLF

Max LLF Current datasheet

Balanced LLF

Max LLF

Connections/s 350,000 150,000 75,000 350,000 350,000 75,000

Concurrent connections 9 million 3 million 1.5million 10million 7million 1.5million

FW+NAT packets/s Not published (~8.8Mpps w/4

SPCs)

80Mpps 100Mpps Not published (~17.6Mpps w/8

SPCs)

160Mpps 220Mpps

FW+NAT throughput (large packets)

60Gbps 160Gbps 200Gbps 120Gbps 320Gbps 440Gbps

FW+NAT throughput (IMIX*)

20Gbps 160Gbps 200Gbps 45Gbps 320Gbps 440Gbps

FW+NAT throughput (64byte packets)

Not published (~4.4Gbps with 4

SPCs)

41Gbps 51.2Gbps Not published (~8.8Gbps with

8 SPCs)

82Gbps 112.6Gbps

• ‘Balanced’ loadout is 4 IOC, 2 SPC (SRX5600) and 8 IOC, 4 SPC (SRX5800)

• ‘Max’ loadout is the more extreme 5 IOC, 1 SPC (SRX5600) and 11 IOC, 1 SPC (SRX5800)

• Balanced is just an arbitrary name for demonstration purposes

•All numbers assume 5Mpps per NP

*IMIX uses average packet size of 320 bytes

Devices & Hardware

2012 srx-architecture-pdf