Chassis Cluster Fabric Interfaces

Supported Fabric Interface Types

In a chassis cluster, the fabric link can be formed using any pair of Ethernet interfaces across the cluster. The fabric link must use a pair of Gigabit Ethernet interfaces.

For details about port and interface usage for management, control, and fabric links, see Understanding SRX Series Chassis Cluster Slot Numbering and Physical Port and Logical Interface Naming.

Jumbo Frame Support

The fabric data link does not support fragmentation. To accommodate this limitation, jumbo frame support is enabled by default on the fabric link, with an maximum transmission unit (MTU) size of 9014 bytes (9000 bytes of payload + 14 bytes for the Ethernet header) on Firewalls. To ensure that traffic traversing the fabric data link does not exceed this limit, we recommend configuring all other interfaces with an MTU that does not exceed the fabric link MTU.

Understand Fabric Interfaces on SRX5000 Line of Firewalls (IOC2 and IOC3)

The fabric interface card supports Modular Interface Cards (MICs), which add Ethernet ports to the services gateway and provide physical connectivity to various network media types. Both MPCs and MICs support fabric links for chassis clusters.

There are two types of IOC3 Modular Port Concentrators (MPCs), each with different built-in MICs, the 24x10GE + 6x40GE MPC and the 2x100GE + 4x10GE MPC.

Due to power and thermal constraints, not all four PICs on the 24x10GE + 6x40GE can be powered on simultaneously. A maximum of two PICs can be powered on at the same time.

Use the set chassis fpc <slot> pic <pic> power off command to select the PICs that you want to power on.

Understand Session RTOs

The data plane software operates in active/active mode and is responsible for flow processing, session state redundancy, and transit traffic handling. All packets belonging to a given session are processed on the same node to ensure consistent security enforcement. The system determines which node owns the active session and forwards all associated packets to that node for processing. After processing, if the egress interface resides on the peer node, the Packet Forwarding Engine forwards the packet to the node for transmission.

To provide session (or flow) redundancy, the data plane software synchronizes its state by transmitting special payload packets, known as runtime objects (RTOs), between nodes over the fabric data link. By exchanging session information between the nodes, RTOs ensure session consistency and stability during a failover, allowing the system to continue processing traffic for existing sessions. To maintain continuous synchronization, the data plane software prioritizes RTO transmission over transit traffic.

The data plane software generates RTOs for UDP and TCP sessions and tracks their state changes. It also synchronizes traffic for IPv4 pass-through protocols such as Generic Routing Encapsulation (GRE) and IPsec.

RTOs for synchronizing a session include:

• Session creation RTOs on the first packet

• Session deletion and age-out RTOs

• Change-related RTOs, including:

  • TCP state changes

  • Timeout synchronization request and response messages

  • RTOs for creating and deleting temporary openings in the firewall (pinholes) and child session pinholes

Understand Data Forwarding

In Junos OS, flow processing occurs on the node where the session for that flow is established and remains active. This approach ensures that consistent security measures are applied to all packets belonging to the session.

In a chassis cluster, traffic can be received on an interface on one node and forwarded out through an interface on the peer node. In active/active mode, the ingress interface for a session may reside on one node, while the egress interface may reside on the other node.

This traversal is required in the following scenarios:

• When packets are processed on one node but must be forwarded through an egress interface on the peer node.

• When packets arrive on an interface on one node but must be processed on the other node.

• When both the ingress and egress interfaces are on the same node, but the packet must be processed on the peer node because the session was established there. In this case, the packet traverses the fabric data link twice. This scenario can occur with certain complex media sessions, such as voice-over-IP (VoIP).

Understand Fabric Data Link Failure and Recovery

Intrusion Detection and Prevention (IDP) services do not support failover. As a result, IDP is not applied to sessions that were established before a failover. IDP services are applied only to new sessions created on the new primary node.

The fabric data link is critical to chassis cluster operation. If the link becomes unavailable, traffic forwarding and runtime object (RTO) synchronization are disrupted, which can result in traffic loss and unpredictable system behavior. On Firewalls, fabric link recovery and synchronization occur automatically.

To prevent this condition, Junos OS uses fabric monitoring to verify the health of the fabric link—or both fabric links in a dual fabric link configuration—by periodically sending probe packets across the fabric links.

If Junos OS detects a fabric fault, the redundancy group 1 (RG1+) status of the secondary node changes to ineligible. A fabric fault is declared when a fabric probe is not received while the fabric interface remains active.

To recover from this state, both fabric links must return to an online state and resume exchanging probes. Once this occurs, all FPCs on the previously ineligible node are reset, transition to the online state, and rejoin the cluster.

If you make any configuration changes while the secondary node is disabled, run the commit command after rebooting the node to synchronize the configuration. If no changes were made, the configuration file remains synchronized with the primary node.

When both the primary and secondary nodes are healthy (that is, no failures are present) and the fabric link goes down, RG1+) on the secondary node becomes ineligible.

When one of the nodes is unhealthy, the RG1+ on the affected node —whether primary or secondary—becomes ineligible.

When both nodes are unhealthy and the fabric link goes down, the RG1+ on the secondary node becomes ineligible. When the fabric link is restored, the node on which RG1+ became ineligible performs a cold synchronization on all Services Processing Units and then transitions to the active-standby state.

• If RG0 is primary on an unhealthy node, RG0 fails over from the unhealthy node to the healthy node. For example, if node 0 is primary for RG0+ and becomes unhealthy, RG1+ on node 0 transitions to an ineligible state after 66 seconds of fabric link failure. RG0+ then fails over to node 1, which is the healthy node.

• Only RG1+ transitions to an ineligible state. RG0 remains in either the primary or secondary state.

Use the show chassis cluster interfaces CLI command to verify the status of the fabric link.