GS1920-48v2 - LACP fails when using two links with Juniper EX4400 EVPN ESI-LAG (Active-Active)

Options
Klaudiusz
Klaudiusz Posts: 2 image  Freshman Member

We are experiencing an issue with LACP on a Zyxel GS1920-48v2 switch connected to two Juniper EX4400 switches configured with EVPN ESI-LAG (Active-Active Multihoming).

When only one physical link is active, LACP establishes successfully and traffic is forwarded normally. However, when we enable the second link, both ports on the Zyxel enter the BLOCKING state, and the LAG stops forwarding traffic.

Our network environment:

  • Zyxel switch: GS1920-48v2
  • Firmware: 5.00 ABMJ.3
  • LACP: Enabled (Active)
  • LACP Timeout: 1 second
  • RSTP: Disabled on Zyxel
  • Loop Guard: Disabled
  • Upstream switches: 2 × leaf - Juniper EX4400

We tested both physical connections independently:

  • Port 47 only: LACP works correctly.
  • Port 48 only: LACP works correctly.
  • Both ports enabled simultaneously: LACP fails, and both ports enter the BLOCKING state.

The Zyxel displays LACP as the LAG status, but the Synchronized Ports field remains empty when both links are connected.

On the Juniper EX4400 switches, we verified that both devices advertise identical LACP System IDs and Actor Keys, as required for EVPN multihoming.

Both Juniper EX4400 switches advertise the same LACP System ID and Actor Key,

The LACP state differs between the two devices when both links are enabled:

LEAF 1 - EX4400

Receive State: Current
Mux State: Collecting distributing
Actor:   Syn Yes, Col Yes, Dist Yes
Partner: Syn Yes, Col No,  Dist No

LEAF 2 - EX4400

Receive State: Current
Mux State: Waiting
Actor:   Syn No, Col No, Dist No
Partner: Exp Yes, Def Yes, Syn No

We have also tested a other switches connected to the EX4400 EVPN ESI-LAG infrastructure, and both LACP links work correctly.

Other servers connected through ESI-LAG also work without issues.

This suggests a possible LACP interoperability issue with the Zyxel GS1920-48v2.


Does the GS1920-48v2 officially support LACP connections to two switches operating as an EVPN ESI-LAG or MC-LAG pair?

Are there any known issues where enabling a second LACP member causes both ports to enter the BLOCKING state?

All Replies

  • Zyxel_Judy
    Zyxel_Judy Posts: 2,789
    Zyxel Certified Network Engineer Level 2 - Nebula Zyxel Certified Network Engineer Level 2 - Switch Zyxel Certified Network Engineer Level 2 - Security Zyxel Certified Network Engineer Level 1 - Nebula
    image  Zyxel Employee
    Options

    Hi @Klaudiusz ,

    Regarding the link aggregation behavior on Zyxel switches, it follows the standard LACP mechanism. The switch determines whether multiple ports belong to the same LAG based on the LACP information it receives — specifically the Partner System ID (System Priority + System MAC) and Partner Key. These values must match across the ports for them to be treated as members of the same LAG.

    To verify this further, could you please share:

    • A packet capture of the LACP traffic on both member ports (47 and 48) of the GS1920-48v2
    • The GS1920-48v2’s tech support file

    Zyxel_Judy

  • Zyxel_Judy
    Zyxel_Judy Posts: 2,789
    Zyxel Certified Network Engineer Level 2 - Nebula Zyxel Certified Network Engineer Level 2 - Switch Zyxel Certified Network Engineer Level 2 - Security Zyxel Certified Network Engineer Level 1 - Nebula
    image  Zyxel Employee
    Options

    Hi @Klaudiusz ,

    While we wait for the packet capture and tech support file, one more thing to try in parallel: in a similar case (Zyxel switch connected to two Dell switches in MLAG — comparable to your Juniper ESI-LAG setup), the same symptom (one link fine, second link causes BLOCKING) was resolved by using different port numbers on the two chassis — e.g. port 1 on chassis #1 and port 2 on chassis #2, instead of the same port number on both.

    Different vendor/technology, so not guaranteed here, but worth a quick try. Could you change the ports so EX4400 #1 and EX4400 #2 use different port numbers (not matching), and let us know the result?

    Still need the packet capture + tech support file either way, to confirm root cause.

    Zyxel_Judy