Understanding SRX5600 and SRX5800 Architecture and Flow Processing

This topic introduces the architecture for the SRX5600 and SRX5800 devices and uses it as a model to explain IP version 6 (IPv6) processing. Flow processing is similar on other SRX Series and J-series devices.

High-end SRX Series Services Gateway devices include I/O cards (IOCs) and Services Processing Cards (SPCs) that each contain processing units that process a packet as it traverses the device. These processing units have different responsibilities.

• A Network Processing Unit (NPU) runs on an IOC. An IOC has one or more NPUs. An NPU processes packets discretely and performs basic flow management functions.

  When an IPv6 packet arrives at an IOC, the packet flow process begins. The NPU takes the following actions:

  • It performs the following IPv6 sanity checks for the packet.
    • For the IPv6 basic header, it performs the following header checks:
      • Version. It verifies that the header specifies IPv6 for the version.
      • Payload length. It checks the payload length to ensure that the combined length of the IPv6 packet and the Layer 2 (L2) header is greater than the L2 frame length.
      • Hop limit. It checks to ensure that the hop limit does not specify 0 (zero)
      • Address checks. It checks to ensure that the source IP address does not specify ::0 or FF::00 and that the destination IP address does not specify ::0 or ::1.
    • It performs IPv6 extension header checks, including the following:
      • Hop-by-hop options. It verifies that this is the first extension header to follow the IPV6 basic header.
      • Routing extension. It verifies that there is only one routing extension header.
      • Destination options. It verifies that no more than two destination options extension headers are included.
      • Fragment. It verifies that there is only one fragment header.

      Note: It treats any other extension header as a Layer 4 (L4) header.

    • It performs L4 TCP, UDP,and ICMP6 protocol checks, including the following:
      • UDP. It checks to ensure that UDP packets, other than a first-fragment packet, are at least 8 bytes long.
      • TCP. It checks to ensure that ICMPv6 packets, other than a first-fragment packet, are at least 20 bytes long.
      • ICMPv6. It checks to ensure that ICMPv6 packets, other than a first-fragment packet, are at least 8 bytes long.
  • If the packet specifies a TCP or a UDP protocol, it creates a tuple from the packet header data using the following information:
    • Source IP address.
    • Destination IP address.
    • Source port.
    • Destination port.
    • Protocol.
    • Virtual router identifier (VRID). The device looks up the VRID from a VRID table.
  • For Internet Control Message Protocol version 6 (ICMPv6) packets, the tuple contains the same information as used for the TCP and the UDP search key, except for the source and destination port fields. The source and destination port fields are replaced with the following information extracted from the ICMPv6 packet:
    • For ICMP error packets: The pattern "0x00010001"
    • For ICMP information packets: The type, or code, field identifier
  • For packets with an Authentication Header (AH) or an Encapsulating Security Payload (ESP) header, the search key is the same as that used for the TCP and the UDP tuple, except for the source and destination fields. In this case, the security parameter index (SPI) field value is used instead of the source and destination ports.
  • If a session exists for the packet’s flow, the NPU sends the packet to the SPU that manages the session.
  • If a matching session does not exist,
    • The NPU sends the packet information to the central point (CP), which creates a pending session.
    • The CP selects an SPU to process the packet and create sessions for it.
    • The SPU then sends session creation messages to the CP and the ingress and egress NPUs, directing them to create a session for the packet flow.
• A central point which can run on a dedicated SPU, or share the resources of one if there is only one SPU. A CP takes care of arbitration and allocation of resources, and it distributes sessions in an intelligent way. The CP assigns an SPU to be used for a particular session when the SPU processes the first packet of its flow.
  • Juniper Networks SRX5000 line devices have at least two SPUs. If an SRX5000 line device has only two SPUs, one acts in combination (combo mode ) serving as both the CP and the SPU.
  • For SRX3000 line devices, the CP and an SPU always run in combo mode.
• One or more SPUs that run on a Services Processing Card (SPC). All flow-based services for a packet are executed on a single SPU, within the context of a session that is set up for the packet flow.

  The SPC for SRX5000 line devices has two SPUs. The SPC for SRX3000 line devices has one SPU.

  Several SPCs can be installed in a chassis.

  Primarily, an SPU performs the following tasks:

  • It manages the session and applies security features and other services to the packet.
  • It applies packet-based stateless firewall filters, classifiers, and traffic shapers.
  • If a session does not already exist for a packet, it sends a request message to the NPU that performed the search for the packet’s session, to direct it to add a session for it.

These discrete, cooperating parts of the system store the information identifying whether a session exists for a stream of packets and the information against which a packet is matched to determine if it belongs to an existing session.

Related Topics

• Understanding Sessions for IPv6 Flows
• Understanding IP Version 6 (IPv6)