SRX Reth Interface Down but Physical Links Up? Chassis Cluster and LACP Fixes

The thread title keeps repeating on the Juniper community and r/Juniper: "Chassis cluster + LACP, reth interface down" or "RETH interface showing as down even though the physical interface is up." The scenario is always a variant of the same thing — member ports show link, but the redundant Ethernet interface refuses to pass traffic. Juniper's own KB confirms the two most common causes: LACP flapping the reth, and redundancy-group state problems. Here is the complete field path.

Step 1: Read the Cluster State First

show chassis cluster status

Before touching the reth, confirm the cluster is healthy: one node must be primary for redundancy groups 0 and 1, priority values must match your design, and neither node should be in disabled or lost state. If redundancy group 0 has failed over unexpectedly, look at show log chassisd before anything else — an unstable cluster makes every reth symptom misleading.

Cause 1: LACP Is Down on the Reth

Juniper's KB is explicit: if LACP is configured on the reth and LACP goes down, the reth goes down even though physical links stay up. Check both member links:

show lacp interfaces reth1
show lacp statistics interfaces reth1

Healthy output shows both child links with state Collecting distributing and a stable actor/partner system ID. Common failure patterns from the community threads:

• The switch facing the cluster does not run LACP at all — a static LAG on one side and LACP on the other never forms. Match modes on both ends.
• Only one member link of the reth is cabled to the switch's LAG (a classic lab mistake that passes small tests then breaks under load).
• Speed or duplex negotiated differently on the two child links, so LACP PDUs time out on one member.

Physical-layer doubt? Run the isolation method from our show interfaces extensive guide on each child link before blaming the cluster.

Cause 2: Both Reth Members Live on the Same Node

A reth is only "redundant" when one member is on node0 and the other on node1. If both child links belong to the same node, a single chassis event takes the interface away. Verify:

show interfaces reth1 extensive | match "Redundancy|Physical"

Redundancy information should list one member per group. The community discussion about chassis cluster with LACP and reth down walks exactly this check: cabling first, LACP config second, cluster state third.

Cause 3: Redundancy Group and Interface Monitoring

If your design uses redundancy-group 1 interface-monitor, a monitored interface going down can fail the whole group to the other node, taking all reths with it — even the ones whose own links are fine:

show chassis cluster interfaces
show chassis cluster information detail

Tune weights so a single unimportant access port cannot fail over the cluster, and remember that interface monitoring measures link, not path health. For reachability-style failover, the reth plus policy approach described in our SRX zone and policy guide is more predictable.

Cause 4: Fab and Control Link Health

The fabric (fab0/fab1) and control links carry cluster state. If they degrade, node transitions look like interface problems:

show interfaces fab0 extensive
show log messages | last 50

A flapping fab link produces repeated dn_eth_port_monitor or node-failover messages. Repair or re-cable the fabric before re-testing the reth.

Quick Reference Table

Once the reth is stable again, confirm sessions build and translate normally with the method in our SRX NAT flow-session guide, and if VPN tunnels ride this reth, the IKE phase troubleshooting guide shows how node transitions tear down and rebuild them.