Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Asymmetric Traffic Flow Support in Multinode High Availability

Overview

Starting in Junos OS Release 23.4R1, SRX Series Firewalls in Multinode High Availability support asymmetric traffic flows.

For stateful services or to perform deep packet inspection, a firewall requires to see both directions of each flow session.

Asymmetric traffic flow happen when the flow of packets traverses from a source network to a destination network using one path (through node 1) and takes a different return path (using node 2). This asymmetric flow can occur when traffic flows across a Layer-3 routed networks.

In a typical high availability deployment, you have multiple routers and switches on the both sides of the network. The routers use a next-hop path to forward each packet flow; but routers might not use the same path for the return traffic. In a Multinode High Availability setup, routers send packets to the firewall based on current routing path, which can result in asymmetric traffic flows

This different handling of traffic directions can cause some packets to get dropped by one or both high availability nodes. This happens because neither node can capture the entire traffic flow, leading to potential inconsistencies and dropped packets.

To handle asymmetric traffic flows, the Multinode High Availability requires an additional link known as Inter Chassis Datapath (ICD). ICD can to route the traffic between two nodes. The ICD enables the nodes to redirect asymmetric traffic flows to the peer node that is originally in charge of providing stateful services for the flows.

This feature ensures that security checks (such as three-way handshake and sequence check with window scale factor) can be performed for asymmetric traffic flows vs traditional (mandator) symmetric flows.

How Multinode High Availability Supports Asymmetric Traffic Flow

Without Asymmetric Traffic Flow Support

The bidirectional packets of the same flow are delivered to a different SRX Series device in Multinode High Availability setup by neighboring routers or switches as shown Figure 1

Figure 1: Packet Flow without Asymmetric Traffic Flow Support Packet Flow without Asymmetric Traffic Flow Support

Outbound traffic from network B to network A passes through node 1 (SRX-01) and return traffic (inbound traffic) flows from network A to network B through node 2 (SRX-02).

In this case of asymmetric traffic flow, due to lack of complete state information about bidirectional traffic of the same flow, SRX Series Firewall (in this example SRX-02) drops packets.

With Asymmetric Traffic Flow Support

To support asymmetric traffic flow, Multinode High Availability uses Inter Chassis Datapath (ICD). The ICD forwards packets of asymmetric traffic flows between two SRX Series devices in a high availability setup.

Figure 2: Packet Flow with Asymmetric Traffic Flow Support Packet Flow with Asymmetric Traffic Flow Support

In this case, the Multinode High Availability system creates a new routable link between the nodes. This routable link enables the nodes to forward asymmetrical flows to the original node that can perform security inspection for the flow. That is, the node 2 (SRX-02) forwards the inbound traffic to the node 1 (SRX-01) instead to a next-hop router. The SRX Series Firewall performs security inspection for the packets of the bidirectional flow.

How Inter Chassis Datapath (ICD) Works?

Multinode High Availability ICD carries data traffic and forwards the data flows to the peer node. This link does not forward interchassis link (ICL) packets.

The workflow includes the following steps:

  1. When a Multinode High Availability node receives a data packet, security services running on the node determines whether to forward the packet to the peer node or process it locally. The decision to forward the packet depends on:
    • Packet's flow session states or service type
    • State of SRG associated with the flow of the packet
  2. If the peer node is reachable over the ICD, security services on a node can send and receive packets between the nodes.
  3. Once the peer node receives a forwarded data packet through the ICD, it performs security inspection based on the configured policies.

To use ICD for packet forwarding between nodes, you must:

  • Assign ICD to the loopback interface with a routable path to the other node.
  • Ensure that the ICD has path diversity for the highest reliability by assigning multiple physical interfaces to the ICD.

Planning Interfaces for ICL and ICD

In a Multinode High Availability configuration, the ICL and ICD physical interfaces must be active and operational to accommodate asymmetric traffic flows. The ICL and ICD interfaces facilitate communication between nodes in the high availability setup, and their status will influence the packet processing. If either interface is non-functional, it will affect support for asymmetric traffic flows. Therefore, it is crucial to ensure the proper functioning of these interfaces for optimal network performance.

When you have multiple physical interfaces connected to the ICL, and one of these interfaces that's being actively used to process packets fails, the data flow switches to use another available physical interface associated with ICL. If all physical interfaces associated with ICL are down, SRX Series Firewalls lose the ICL connection. In this case, the SRX Series nodes can not exchange RTO messages and can not support asymmetric traffic flows.

Use different loopback interfaces for ICL and for ICD in a Multinode High Availability setup.

Nodes learn the route to reach IP address of the peer node's ICD through static or dynamic routing protocols (Example: BGP). Multinode High Availability setup leverages existing routing functionality on each SRX Series Firewall to route the packets.

ICL and ICD States Affecting Asymmetric Traffic

Table 1 shows how the states of BFD between the nodes are dependent on assigned physical interfaces of both ICL and ICD.

Table 1: ICL and ICD States Affecting Asymmetric Traffic Flow Support
ICL ICD Service for Asymmetric Traffic Flow
Physical Interface BFD State Physical interface BFD State
Up Up Up Up Up
Up Up Down Down Down
Down Down Up Up Down
Up Down Up Down Down
Down Down Down Down Down

Configure Asymmetric Traffic Flow Support in Multinode High Availability

Read this topic to understand how to configure asymmetric traffic flow support for SRX Series Firewalls deployed in the Multinode High Availability solution. The example covers configuration in active/backup mode when SRX Series Firewalls are connected to routers on both sides (Layer 3 deployment).

Junos OS Release 23.4R1 brings in a new feature that supports asymmetric traffic flow. Asymmetric routing is a scenario where the path of packets in one direction is different from the origin path.

In a typical high availability deployment, you have multiple routers and switches on the both sides of the network. The routers use a next-hop path to forward each packet flow; but routers might not use the same path for the return traffic. In a Multinode High Availability setup, routers send packets to the firewall based on current routing path, which can result in asymmetric traffic flows

To handle asymmetric traffic flows, the Multinode High Availability infrastructure employs a new link known as Inter Chassis Datapath (ICD). ICD has the ability to forward the traffic between two nodes. It enables the nodes to redirect asymmetric traffic flows to the peer node that is originally in charge of providing stateful services for these flows.

Follow this configuration example to set up Multinode High Availability to support asymmetric routing and to validate the configuration on your device.

Tip:
Table 2: Time Estimates

Reading Time

Less than 15 minutes.

Configuration Time

Less than an hour.

Example Prerequisites

Table 3 lists the hardware and software components that support the configuration.

Table 3: Requirements

Supported Hardware

  • SRX5800, SRX5600, SRX5400 with SPC3, IOC3, IOC4, SCB3, SCB4, and RE3

  • SRX4600, SRX4200, SRX4100, SRX2300, SRX1600, and SRX1500

Supported Software

Junos OS Release 23.4R1

Licensing requirements

No separate license is required to configure Multinode High Availability. Licenses are unique to each SRX Series and cannot be shared between the nodes in a Multinode High Availability setup. Therefore, you must use identical licenses on both the nodes.

In this example, we've used two supported SRX Series Firewalls with Junos OS Release 23.4R1 and two Juniper Networks(R) MX960 Universal Routing Platform as upstream and downstream routers.

Before You Begin

Benefits

The SRX Series Firewall in a Multinode High Availability handles asymmetrically routed packets efficiently. This process ensures reliable and consistent handling of stateful services for these packets, improving overall performance and minimizing packet loss and inconsistencies in the network.

Know more

Multinode High Availability

Functional Overview

Table 4 provides a quick summary of the configuration components deployed in this example.

Table 4: Configuration Components

Technologies used

  • High availability

  • Routing policy

  • Routing options

Primary verification tasks

  1. Verify the high availability on both the nodes in the setup.

  2. Verify the Multinode High Availability data plane statistics.

Topology Illustration

Figure 3 shows the topology used in this example.

Figure 3: Multinode High Availability in Layer 3 Network with Interchassis Datapath (ICD) Multinode High Availability in Layer 3 Network with Interchassis Datapath (ICD)

As shown in the topology, two SRX Series Firewalls are connected to adjacent routers on trust and untrust side forming a BGP neighborship.

An encrypted logical interchassis link (ICL) connects the nodes over a routed network. The nodes communicate with each other using a routable IP address (floating IP address) over the network. In general, you can use aggregated Ethernet (AE) or a revenue Ethernet port on the SRX Series Firewalls to setup an ICL connection. In this example, we've used GE ports for the ICL. We've also configured a routing instance for the ICL path to ensure maximum segmentation.

Two physical links (ICD) connect two SRX Series Firewalls. The physical interfaces on both the nodes are forming the MNHA ICD connections. In this example, use two dedicated revenue interfaces to configure ICD.

Loopback interfaces are used to host the IP addresses on SRX Series and routers.

In a typical high availability deployment, you have multiple routers and switches on the northbound and southbound sides of the network. For this example, we are using two routers on both sides of SRX Series Firewalls.

Topology Overview

In this example, you'll establish high availability between the SRX Series Firewalls and establish ICD (interchassis datapath) for providing support to handle asymmetric routing support.

In a typical high availability deployment, you have multiple routers and switches on the northbound and southbound sides of the network. For this example, we are using two routers on both sides of SRX Series Firewalls.

Table 5 and Table 6 show the details on interfaces configuration used in this example.

Table 5: Interfaces and IP Address Configuration on Security Devices
Device Interface Zone IP Address Configured For
SRX-01 lo0 Trust 10.1.100.1/32

Local forwarding address used to forward data packet over ICD link.

ge-0/0/2 ICL-Zone 10.22.0.1/24 Interchassis link (ICL)
ge-0/0/1 and ge-0/0/0 Trust
  • 10.200.200.2/24
  • 10.100.100.2/24
Interchassis Datalink connecting two SRX Series Firewalls
ge-0/0/4 Untrust 10.4.0.1/24 Connects to R2 router
ge-0/0/3 Trust 10.2.0.2/24 Connects to R1 router
SRX-02 lo0 Trust 10.1.200.1/32

Local forwarding address used to forward data packet over ICD link.

ge-0/0/2 ICL-zone 10.22.0.2/24 Interchassis link (ICL)
  • ge-0/0/0
  • ge-0/0/1
Trust
  • 10.100.100.1/24
  • 10.200.200.1/24
Interchassis Data link (ICD)
ge-0/0/3 Trust 10.3.0.2/24 Connects to R1 router
ge-0/0/4 Untrust 10.5.0.1/24 Connects to R2 router

Interfaces and IP Address Configuration on Routing Devices

Table 6: Interfaces and IP Address Configuration on Routing Devices
Device Interface IP Address Configured for
R2 lo0 10.111.0.2/32 Loopback interface address of R2
ge-0/0/0 10.4.0.2/24 Connects to SRX-02
ge-0/0/1 10.5.0.2/24 Connects to SRX-01
ge-0/0/2 10.6.0.1/24 Connects to external network
R1 lo0 10.111.0.1/32 Loopback interface address of R1
ge-0/0/0 10.2.0.1/24 Connects to SRX-01
ge-0/0/1 10.3.0.1/24 Connects to SRX-02
ge-0/0/2 10.1.0.1/24 Connects to internal network

Configuration

Note:

For complete sample configurations on the DUT, see:

Junos IKE package is required on your SRX Series Firewalls for Multinode High Availability configuration. This package is available as a default package or as an optional package on SRX Series Firewalls. See Support for Junos IKE Package for details.

If the package is not installed by default on your SRX Series firewall, use the request system software add optional://junos-ike.tgz to install it. You require this step for ICL encryption.

  1. Configure interfaces.
    1. Configure interface used to connect trust network.
      SRX-01
      SRX-02
    2. Configure interface used to connect untrust network.
      SRX-01
      SRX-02
    3. Configure interface for ICL.
      SRX-01
      SRX-02
    4. Configure interface for ICD.
      SRX-01
      SRX-02
    5. Configure loopback interface.
      SRX-01
      SRX-02
  2. Configure security zones, assign interfaces to the zones, and specify the allowed system services for the security zones
    1. Configure trust zone.
      SRX-01
      SRX-02
    2. Configure untrust zone.
      SRX-01
      SRX-02
    3. Configure ICL zone.
      SRX-01
      SRX-02
  3. Configure Multinode High Availability local node.
    1. Configure local node.
      SRX-01

      Use IP address 10.1.100.1 as local forwarding IP. This IP address is the IP address of loopback interface.

      SRX-02
    2. Configure peer node.
      SRX-01

      You'll use the ge-0/0/2 interface for communicating with the peer node using the ICL. You are using IP address 10.1.200.1 as peer forwarding IP. This IP address is the IP address of loopback interface on the peer node.

      SRX-02
    3. Configure SRG0.
      SRX-01
      SRX-02
    4. Configure SRG 1.
      SRX-01
      SRX-02
      Note: You must specify the active signal route along with the route-exists policy in the policy-options statement. When you configure the active-signal-route with if-route-exists condition, the HA module adds this route to the routing table.
  4. Configure routing-options
    SRX-01
    SRX-02
  5. Configure policy options.
    SRX-01
    SRX-02
  6. Specify options to secure high availability traffic flow between the nodes through ICL.
    SRX-01 and SRX-02
    1. Configure PKI options.
    2. Define Internet Key Exchange (IKE) configuration. An IKE configuration defines the algorithms and keys used to establish a secure connection.
    3. IPsec proposal protocol and encryption algorithm
  7. Configure the security policy .
    SRX-01 and SRX-02
    Tip:

    The security policy shown in this example is only for demonstration. You should configure security policies as per your network needs. Ensure that your security policies allow only the applications, users, and devices that you trust.

  8. Configure BFD peering sessions options and specify liveness detection timers.
    (SRX-01)

    SRX-02

Verification

Use the following show commands to verify the feature in this example.

Table 7: Verification Tasks
Commands Verification Task
show chassis high availability information

Displays Multinode High Availability details including status.

show chassis high-availability data-plane statistics

Displays ICD data packets statistics.

Check Multinode High Availability Details

Purpose

View and verify the details of the Multinode High Availability setup configured on your security device.

Action

From operational mode, run the following command:

SRX-01

SRX-02

Meaning

Verify these details from the command output:

  • Local node and peer node details such as IP address and ID.

  • The field Peer ICD Conn State: UP indicates that the ICD link is established and operational.

Verify ICD Data Packets Statistics

Purpose

Check if the ICD is operational and facilitating the transfer of data packets between the nodes.

Action

From operational mode, run the following command:

Meaning

The field ICD Data indicates ICD is routing asymmetric traffic flow in Multinode High Availability setup.

Set Commands on All Devices

Set command output on all devices.

SRX-01 (Node 1)

SRX-02 (Node 2)

Router -1

Router-2

Show Configuration Output

From configuration mode, confirm your configuration by entering the show high availability, , show security zones, and show interfaces. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

SRX-01 (Node 1)

SRX-02 (Node 2)