This article explains why you cannot manage the secondary node through fxp0 when fab-link auto-recovery happens. This is a limitation of most Branch SRX having FXP0 interface defined through a data port, or an onboard port.
If Junos OS detects fabric faults, RG1+ status of the secondary node changes to ineligible. It determines that a fabric fault has occurred if a fabric probe is not received but the fabric interface is active. To recover from this state, both the fabric links need to come back to online state and should start exchanging probes. As soon as this happens, all the FPCs (Flexible PIC Concentrator) on the previously ineligible node will be reset. Then they change to online state and rejoin the cluster.
{primary:node0} root@SRX-A> show chassis cluster status Monitor Failure codes: CS Cold Sync monitoring FL Fabric Connection monitoring GR GRES monitoring HW Hardware monitoring IF Interface monitoring IP IP monitoring LB Loopback monitoring MB Mbuf monitoring NH Nexthop monitoring NP NPC monitoring SP SPU monitoring SM Schedule monitoring CF Config Sync monitoring Cluster ID: 1 Node Priority Status Preempt Manual Monitor-failures Redundancy group: 0 , Failover count: 1 node0 100 primary no no None node1 0 secondary no no FL Redundancy group: 1 , Failover count: 3 node0 255 primary no yes None node1 0 ineligible no yes FL {primary:node0} root@SRX-A> show chassis cluster interfaces Control link status: Up Control interfaces: Index Interface Monitored-Status Internal-SA 0 fxp1 Up Disabled Fabric link status: Down Fabric interfaces: Name Child-interface Status (Physical/Monitored) fab0 ge-0/0/2 Up / Down fab0 fab1 ge-9/0/2 Up / Down fab1 Redundant-ethernet Information: Name Status Redundancy-group reth0 Down Not configured reth1 Up 1 reth2 Up 1 Redundant-pseudo-interface Information: Name Status Redundancy-group lo0 Up 0
C:\Windows\System32>ping 10.10.10.10 -t Pinging 10.10.10.10 with 32 bytes of data: Reply from 10.10.10.10: bytes=32 time=7ms TTL=62 Reply from 10.10.10.10: bytes=32 time=6ms TTL=62 Reply from 10.10.10.10: bytes=32 time=7ms TTL=62 Reply from 10.10.10.10: bytes=32 time=9ms TTL=62 Reply from 10.10.10.10: bytes=32 time=11ms TTL=62 Reply from 10.10.10.10: bytes=32 time=3ms TTL=62 Reply from 10.10.10.10: bytes=32 time=5ms TTL=62 Reply from 10.10.10.10: bytes=32 time=6ms TTL=62 Reply from 10.10.10.10: bytes=32 time=6ms TTL=62 Reply from 10.10.10.10: bytes=32 time=8ms TTL=62 Reply from 10.10.10.10: bytes=32 time=9ms TTL=62 Request timed out. Request timed out. Request timed out. Request timed out.
This is a limitation of most Branch SRX having fxp0 interface defined through a data port, or an onboard port. When the secondary node changes to ineligible state, the fxp0 becomes unreachable.High-End SRX and some new Branch SRX that have dedicated fxp0 interface does NOT have this limitation.
2024-09-02: minor non tech changes2020/07/17: Tagged for archival; EOL devices; content is still relevant