SRX

I need an IEEE 802.3ad/LACP aggregate for link redundancy and bandwidth utilization.  Current Junos 26.2R1.7 does not expose 802.3ad on the NFX150 physical interfaces. Is there an existing PR/RFE for NFX150 LAG/LACP support, and if not, can an RFE be submitted?  Is there a reason why this hasn't been implemented?  Is there any supported mechanism on NFX150-S1 for active/standby redundancy between two Ethernet interfaces connected to the same switch, other than spanning tree?  I am requesting this via the ge-1/0/1 and ge-1/0/2 sfp ports.

------------------------------
GIANLUCA BRUNO
------------------------------

I have limited experience here. My answer to you is to find a point of mitigation in the topology. LACP has a tendency to clash with other protocols. That start point gets more finicky the further back you try. So I use vlacp all the way back. Light use is recommended on my net.

------------------------------
Adrian Aguinaga
B.S.C.M. I.T.T. Tech
(Construction Management)
A.A.S. I.T.T. Tech
(Drafting & Design)
------------------------------

LACP conflicting with other protocols? Not in Junos at least. I'd struggle to remember any occasion on any OS where LACP was the source of problems with other protocols. Do you have any examples?

Original Message:
Sent: 08-27-2026 19:52
From: eugene1973
Subject: NFX150 - LACP

I have limited experience here. My answer to you is to find a point of mitigation in the topology. LACP has a tendency to clash with other protocols. That start point gets more finicky the further back you try. So I use vlacp all the way back. Light use is recommended on my net.

------------------------------
Adrian Aguinaga
B.S.C.M. I.T.T. Tech
(Construction Management)
A.A.S. I.T.T. Tech
(Drafting & Design)
------------------------------

I'm sorry if my statement seems untrue. I would agree normally. I have to at least try to get lacp on the srx. So, for that im sorry. My Asus ap's and media bridge have the lacp, but I need to see about how those work. I know its running on them. They are finicky and would normally timeout the net until recently. The way I fixed this early on was to use my switch stack with vlacp only. Now I need to check again, but lacp fails completely on that stack. Maybe its the direction which im taking this now, but it is too dense. I have multilink trunks working, and thats where I think it doesnt get along. My locale may very well have some to do with it. Getting it working further back in the topology was one of my observations. It's not even on the srx. MY locale? How about yours?

------------------------------
Adrian Aguinaga
B.S.C.M. I.T.T. Tech
(Construction Management)
A.A.S. I.T.T. Tech
(Drafting & Design)
------------------------------

Original Message:
Sent: 08-28-2026 03:00
From: fb35523
Subject: NFX150 - LACP

LACP conflicting with other protocols? Not in Junos at least. I'd struggle to remember any occasion on any OS where LACP was the source of problems with other protocols. Do you have any examples?

Original Message:
Sent: 08-27-2026 19:52
From: eugene1973
Subject: NFX150 - LACP

I have limited experience here. My answer to you is to find a point of mitigation in the topology. LACP has a tendency to clash with other protocols. That start point gets more finicky the further back you try. So I use vlacp all the way back. Light use is recommended on my net.

------------------------------
Adrian Aguinaga
B.S.C.M. I.T.T. Tech
(Construction Management)
A.A.S. I.T.T. Tech
(Drafting & Design)
------------------------------

My thoughts about protocol are this. My multilink trunks run and are at 8 links. That is maximum. MLT by Nortel may not exist in any newer versions with them but Cisco might. 802.3ad is covered here. It was way scary to get working. I suggest 10g minimum. It is proprietary. Lacp is probably more inherent. So by protocol clash i mean that MLT and lacp may never run together, and I can't confirm this. Either way sparcity and density come to mind. My locale is a factor I believe as well. Unified signals that routers designate are my thoughts.

------------------------------
Adrian Aguinaga
B.S.C.M. I.T.T. Tech
(Construction Management)
A.A.S. I.T.T. Tech
(Drafting & Design)
------------------------------

Original Message:
Sent: 08-28-2026 15:15
From: eugene1973
Subject: NFX150 - LACP

I'm sorry if my statement seems untrue. I would agree normally. I have to at least try to get lacp on the srx. So, for that im sorry. My Asus ap's and media bridge have the lacp, but I need to see about how those work. I know its running on them. They are finicky and would normally timeout the net until recently. The way I fixed this early on was to use my switch stack with vlacp only. Now I need to check again, but lacp fails completely on that stack. Maybe its the direction which im taking this now, but it is too dense. I have multilink trunks working, and thats where I think it doesnt get along. My locale may very well have some to do with it. Getting it working further back in the topology was one of my observations. It's not even on the srx. MY locale? How about yours?

------------------------------
Adrian Aguinaga
B.S.C.M. I.T.T. Tech
(Construction Management)
A.A.S. I.T.T. Tech
(Drafting & Design)
------------------------------


Original Message:
Sent: 08-28-2026 03:00
From: fb35523
Subject: NFX150 - LACP

LACP conflicting with other protocols? Not in Junos at least. I'd struggle to remember any occasion on any OS where LACP was the source of problems with other protocols. Do you have any examples?

Original Message:
Sent: 08-27-2026 19:52
From: eugene1973
Subject: NFX150 - LACP

I have limited experience here. My answer to you is to find a point of mitigation in the topology. LACP has a tendency to clash with other protocols. That start point gets more finicky the further back you try. So I use vlacp all the way back. Light use is recommended on my net.

------------------------------
Adrian Aguinaga
B.S.C.M. I.T.T. Tech
(Construction Management)
A.A.S. I.T.T. Tech
(Drafting & Design)
------------------------------

If you use the NFX as a virtual SRX platform, reth interfaces should be the way to go. Connecting the underlying ge interfaces to separate heth interfaces (the physical ones in the NFX box) would give you proper redundancy. Also, a reth with multiple links actually behaves as a LAG and you should be able to add LACP to the reth interface config. I haven't had the chance to work with the NFX but I'm somewhat familiar with all the SRX platforms and unless LACP on reth is specifically redacted from the NFX, it should work.

I trust that you have read the docs available here for the NFX? https://www.juniper.net/documentation/us/en/software/junos/nfx150-getting-started/topics/topic-map/nfx150-chassis-cluster-overview.html

Here is some info on LACP on a reth: https://www.juniper.net/documentation/us/en/software/junos/chassis-cluster-security-devices/topics/topic-map/security-chassis-cluster-redundant-ethernet-lag-interfaces.html#id-understanding-lacp-on-chassis-clusters

Oh, if you don't have a cluster, you can actually create one with only one unit and leave it without the redundant sibling. The will enable you to use reth interfaces on the single box. This is of course a bit of a quirky workaround, but may be worth it if you cannot find any other solutions (it's not a big deal to configure).

Feature explorer will telly which functions are available for each platform: https://apps.juniper.net/feature-explorer/select-platform.html?typ=1&category=Junos%20Space%20and%20NFX&pid=51400150&platform=NFX150&swName=Junos%20OS&rel=26.2R1&sid=1451&swtab=Junos%20OS

I hope this helps! If you need more info, reach out to your Juniper SE or other contact, or even open a support case.

/Fredrik