Understanding Asymmetric Routing Chassis Cluster Deployment

In this case, chassis cluster makes use of its asymmetric routing capability (see Figure 101). Traffic received by a node is matched against that node’s session table. The result of this lookup determines whether or not that node should process the packet or forward it to the other node over the fabric link. Sessions are anchored on the egress node for the first packet that created the session. If traffic is received on the node in which the session is not anchored, those packets are forwarded over the fabric link to the node where the session is anchored.

Note: The anchor node for the session can change if there are changes in routing during the session.

In this scenario, two Internet connections are used, with one being preferred. The connection to the Trust zone is done by using a redundant Ethernet interface to provide LAN redundancy for the devices in the Trust zone. This scenario describes two failover cases in which sessions originate in the Trust zone with a destination of the Internet (Untrust zone).

• Understanding Failures in the Trust Zone Redundant Ethernet Interface
• Understanding Failures in the Untrust Zone Interfaces

Understanding Failures in the Trust Zone Redundant Ethernet Interface

Under normal operating conditions, traffic flows from the Trust zone interface fe-1/0/0, belonging to reth0.0, to the Internet. Because the primary Internet connection is on node 0, sessions are both created in node 0 and synced to node 1. However, session are only active on node 0.

A failure in interface fe-1/0/0 triggers a failover of the redundancy group, causing interface fe-5/0/0 in node 1 to become active. After the failover, traffic arrives at node 1. After session lookup, the traffic is sent to node 0 because the session is active on this node. Node 0 then processes the traffic and forwards it to the Internet. The return traffic follows a similar process. The traffic arrives at node 0 and gets processed for security purposes—for example, antispam scanning, antivirus scanning, and application of security policies—on node 0 because the session is anchored to node 0. The packet is then sent to node 1 via the fabric interface for egress processing and eventual transmission out of node 1 via interface fe-5/0/0.

Understanding Failures in the Untrust Zone Interfaces

In this case, sessions are migrated from node to node. Under normal operating conditions, traffic is processed by only node 0. A failure of interface ge-0/0/0 on node 0 causes a change in the routing table, so that it now points to interface ge-7/0/0 in node 1. After the failure, sessions in node 0 become inactive, and the passive sessions in node 1 become active. Traffic arriving from the Trust zone is still received on interface fe-1/0/0, but is forwarded to node 1 for processing. After traffic is processed in node 1, it is forwarded to the Internet through interface ge-7/0/0.

In this chassis cluster configuration, redundancy group 1 is used to control the redundant Ethernet interface connected to the Trust zone. As configured in this scenario, redundancy group 1 fails over only if interface fe-1/0/0 or fe-5/0/0 fails, but not if the interfaces connected to the Internet fail. Optionally, the configuration could be modified to permit redundancy group 1 to monitor all interfaces connected to the Internet and fail over if an Internet link were to fail. So, for example, the configuration can allow redundancy group 1 to monitor ge-0/0/0 and make fe-5/0/0 active for reth0 if the ge-0/0/0 Internet link fails. (This option is not described in the configuration examples below.)

Related Topics

• JUNOS Software Feature Support Reference for SRX Series and J Series Devices
• Example: Configuring an Asymmetric Chassis Cluster Pair (CLI)
• Example: Configuring an Asymmetric Chassis Cluster Pair (J-Web)
• Understanding What Happens When Chassis Cluster Is Enabled
• Understanding Chassis Cluster Formation