[SRX] How to use the local interface in a chassis cluster

This scenario is supported in SRX HA:

Active/Passive State (Control):

Chassis Clustering is working in the HA mode by using JSRP.

It is used in the Control link, for HA failover, to select a node as Active with higher priority.

Active/Passive mode (Data only):

All local ports are running with traffic, including the Data Link without redundancy protection.

Use the IGP Cost to set nodes in Active/Passive in data traffic.

By proper design, no traffic is running in Data Link.

Node with lower priority and its interfaces will be disabled, when the control or data link is broken; it finally requires a manual reboot for recovery.

IP Address assigned for each local port:

Static or Dynamic route between FW and routers.

The cost for Active/Passive deployment needs to be adjusted. For example:
```
routerA-----------(ae0)node0(ae1)------------RouterA1
routerB-----------(ae2)node1(ae3)------------RouterB1
```
ae0/ae1/ae2/ae3 are composed of node0 and node1's local interfaces. Routers and firewalls are running OSPF and traffic path is routerA--node0--routerA1; which is decided by OSPF cost. routerB--node1--routerB1 is the backup traffic path.

Here are the statuses of the node0/node1 session, before/after node0 is rebooted:

The traffic path is routerA--node0--routerA1:

ab@SRX3600-1> show security flow session source-prefix 10.10.0.1 
Aug 05 04:17:16
node0:
--------------------------------------------------------------------------

Flow Sessions on FPC2 PIC0:

Session ID: 40072870, Policy name: N2X_traffic_IAC/6, State: Active, Timeout: 1800, Valid
In: 10.10.0.1/1 --> 11.10.0.1/1;61, If: ae0.0, Pkts: 6601, Bytes: 726110
Out: 11.10.0.1/1 --> 10.87.62.97/47091;61, If: ae1.0, Pkts: 0, Bytes: 0
Total sessions: 1

Flow Sessions on FPC9 PIC0:
Total sessions: 0

node1:
--------------------------------------------------------------------------

Flow Sessions on FPC2 PIC0:

Session ID: 40522063, Policy name: N2X_traffic_IAC/6, State: Backup, Timeout: 14394, Valid
In: 10.10.0.1/1 --> 11.10.0.1/1;61, If: ae0.0, Pkts: 0, Bytes: 0
Out: 11.10.0.1/1 --> 10.87.62.97/47091;61, If: ae1.0, Pkts: 0, Bytes: 0
Total sessions: 1

Flow Sessions on FPC9 PIC0:
Total sessions: 0

lab@SRX3600-1> show route 

10.0.0.0/12 *[OSPF/150] 00:04:21, metric 0, tag 0
> to 10.87.62.1 via ae0.0

11.0.0.0/12 *[OSPF/150] 00:04:26, metric 5, tag 0
> to 10.87.62.5 via ae1.0

Reboot node0, before OSPF finds out that ae0.0 and ae1.0 are down and re-calculates node1's session status:

lab@SRX3600-1> show security flow session source-prefix 10.10.0.1 
Aug 05 04:18:26
node1:
--------------------------------------------------------------------------

Flow Sessions on FPC2 PIC0:

Session ID: 40522063, Policy name: N2X_traffic_IAC/6, State: Backup, Timeout: 14324, Valid
In: 10.10.0.1/1 --> 11.10.0.1/1;61, If: ae0.0, Pkts: 0, Bytes: 0
Out: 11.10.0.1/1 --> 10.87.62.97/47091;61, If: ae1.0, Pkts: 0, Bytes: 0
Total sessions: 1

Flow Sessions on FPC9 PIC0:
Total sessions: 0

After OSPF completes the re-calculation:

lab@SRX3600-1> show route 

10.0.0.0/12 *[OSPF/150] 00:00:03, metric 0, tag 0
> to 10.87.62.9 via ae2.0
11.0.0.0/12 *[OSPF/150] 00:00:03, metric 10, tag 0
> to 10.87.62.13 via ae3.0

4.at this time, node1's session changed fromm backup to active, the egress interface refresh to node1's local interface.
lab@SRX3600-1> show security flow session source-prefix 10.10.0.1 
Aug 05 04:18:39
node1:
--------------------------------------------------------------------------

Flow Sessions on FPC2 PIC0:

Session ID: 40522063, Policy name: N2X_traffic_IAC/6, State: Active, Timeout: 1800, Valid
In: 10.10.0.1/1 --> 11.10.0.1/1;61, If: ae0.0, Pkts: 9075, Bytes: 998250
Out: 11.10.0.1/1 --> 10.87.62.97/47091;61, If: ae3.0, Pkts: 0, Bytes: 0
Total sessions: 1

Flow Sessions on FPC9 PIC0:
Total sessions: 0

The traffic path failover to node1 by OSPF is successful; however the time of failover is much longer than the reth interface, it is decided by how long OSPF takes to find out if the interface is down and re-calculate. Maybe some application is interrupting the process, ultimately causing a timeout. Track IP or other ways are recommended to be used in the firewall's upstream or downstream device, to quickly find out if the interface is down.

Knowledge Base