This KB article provides detailed information on how MAC learning replication via ICCP works for both "MC‑AE" and "non‑MC‑AE" VLANs. It also illustrates a scenario where replication functions correctly for one VLAN, while another VLAN does not replicate MAC learning as expected.
Topology
In this environment, we are working with a pair of QFX10002 devices in an MC‑LAG architecture operating at Layer 2, with active/standby links toward a pair of upstream Firewalls that manage routing. The main issue is that MAC learning replication via ICCP is not occurring for certain "non‑MC‑AE" VLANs, while replication works correctly for other hosts learned through non‑MC‑AE links. ICCP and ICL are configured on the same physical link, ae0.
We have Host 1 and Host 2 on VLAN 30, while Host 3 resides on VLAN 70. As shown in the topology:
Host 1 is learned via a non MC-AE single‑homed link connected to "MC‑LAG peer 1". MAC learning for this Host is replicated correctly across ICCP between the peers.
Host 2 is learned via an MC‑AE interface (ae40) which is connected to an access switch. MAC learning for this Host is replicated correctly across ICCP between the peers.
Host 3, however, is learned via a non MC-AE single‑homed link connected to "MC‑LAG peer 2", but this entry is missing on "MC‑LAG peer 1". This indicates that MAC learning replication via ICCP is not taking place in this scenario.
MAC addresses from Hosts:
When checking the ethernet-switching table on "MC‑LAG peer 1" for Host 3 (aa:bb:cc:dd:ee:33), which is connected to "MC‑LAG peer 2", there is no entry present. This indicates that MAC learning replication is not occurring as expected for VLAN 70:
root@MC_LAG_peer_1> show ethernet-switching table aa:bb:cc:dd:ee:33
root@MC_LAG_peer_1>
On VLAN 70 within "Redundancy Group ID: 1", there is no replication for this host. The only entry being replicated from "MC‑LAG peer 2" corresponds to Host 2 (aa:bb:cc:dd:ee:22) on VLAN 30, which—based on traffic hashing—is learned locally on this peer through the MC‑AE interface ae40:
root@MC_LAG_peer_1> show ethernet-switching redundancy-groups remote-macs Redundancy Group ID : 1 Flags : Local Connect,Remote Connect
Service-id Peer-Addr VLAN MAC MCAE-ID Subunit Opcode Flags Status 1 10.10.10.6 30 aa:bb:cc:dd:ee:22 40 0 1 0 Installed
Host 2 is learned locally on "MC‑LAG peer 2", and its entry is successfully replicated via ICCP to "MC‑LAG peer 1", as shown above:
root@MC_LAG_peer_2> show ethernet-switching table aa:bb:cc:dd:ee:22
Routing instance : default-switch Vlan MAC MAC Age GBP Logical NH MAC RTR name address flags Tag interface Index property ID VLAN30 aa:bb:cc:dd:ee:22 DL - ae40.0 0 0
When checking "MC‑LAG peer 2", we can see that "MC‑LAG peer 1" is successfully replicating the single‑homed device on VLAN 30 (Host 1-aa:bb:cc:dd:ee:11). The MAC entry is present and shows as learned via the ICCP/ICL link ae0:
root@MC_LAG_peer_2> show ethernet-switching table aa:bb:cc:dd:ee:11
Ethernet switching table : 4 entries, 4 learnedRouting instance : default-switch Vlan MAC MAC Age GBP Logical NH MAC RTR name address flags Tag interface Index property ID VLAN30 aa:bb:cc:dd:ee:11 DR - ae0.0 0 0
Replication through "Redundancy Group ID: 1" is visible and correctly installed, confirming that MAC learning synchronization is functioning as expected on VLAN 30 for this single‑homed device learned via a non‑MC‑AE interface on "MC‑LAG peer 1":
root@MC_LAG_peer_2> show ethernet-switching redundancy-groups remote-macs Redundancy Group ID : 1 Flags : Local Connect,Remote Connect
Service-id Peer-Addr VLAN MAC Opcode Flags Status 1 10.10.10.5 30 aa:bb:cc:dd:ee:11 1 0 Installed >> We can see is able to sync Mac learning with the other peer via the "Redundancy Group ID : 1" and installed properly.
This behavior—where MAC learning replication works correctly for a single‑homed device on one VLAN but not on another—occurs because ICCP does not replicate MAC learning across the ICL for "non‑MC‑AE" VLANs. When a VLAN is not part of an MC‑AE redundancy group, ARP packets received on that VLAN are not forwarded over the ICL, preventing the peer from learning the MAC. By design, MAC learning from the data path is disabled on the ICL; instead, MAC addresses are installed through ICCP replication.
In other words, VLAN 70 is not included in any redundancy‑group configuration (MC‑AE link). It exists only on a non‑MC‑AE interface connected to Host 3 and on regular Layer 2 trunk ports toward the upstream VRRP devices. As a result, the "MC‑LAG peer 2" treats VLAN 70 as a "non‑MC‑AE" VLAN and does not replicate MAC learning via ICCP.
This behavior is documented in KB34797 [juniper.net], which explains that "non‑MC‑AE" VLAN traffic must be handled through a separate link (not the ICL) to ensure proper forwarding between MC‑LAG peers. Please visit the following link for more information:
https://supportportal.juniper.net/s/article/EX-QFX-MAC-learning-when-assigning-a-non-MC-AE-VLAN-on-ICL
However, there are scenarios where non‑MC‑AE hosts must communicate on the same VLAN with MC‑AE hosts, requiring both MC‑LAG peers to replicate MAC learning to remain synchronized. For example, Host 1 and Host 2 reside on VLAN 30, and both peers correctly learn their MAC addresses. To achieve this, the VLAN must be added to the MC-AE interface (included on the vlan membership of the trunk port) where the redundancy group of ICCP is running. Once included, the device treats it as an "MC‑AE" VLAN regardless of whether traffic originates from a non‑MC‑AE or MC‑AE interface, and MAC learning is replicated across peers.
If we apply the same configuration for Host 3 (aa:bb:cc:dd:ee:33), by adding VLAN 70 to "mc-ae 40", "MC‑LAG peer 2" will flood ARP traffic via the ICL, and MAC learning replication will occur on "MC‑LAG peer 1":
Ethernet switching table : 7 entries, 7 learnedRouting instance : default-switch Vlan MAC MAC Age GBP Logical NH MAC RTR name address flags Tag interface Index property ID VLAN70 aa:bb:cc:dd:ee:33 DR - ae0.0 0 0
Service-id Peer-Addr VLAN MAC Opcode Flags Status 1 10.10.10.6 70 aa:bb:cc:dd:ee:33 1 0 Installed
From the context history, we can see that the MAC address is flooded correctly via the ICL ae0 and added to Kernel without any errors. The reason code "REMOTE_PE" confirms that the entry is being replicated properly from the other peer:
root@MC_LAG_peer_1> show ethernet-switching context-history mac-addr aa:bb:cc:dd:ee:33 ctxt: 58124, Type: MAC,T: 2026-04-29.06:24:08.817778, OP: add, MAC: aa:bb:cc:dd:ee:33, RTT: 1797,BD: 4, VLAN: 70, VNI: 16777215, IFL: ae0.0, IflId: 74, NH 0, Reason: REMOTE_PE , IntrlRsn: Fwd Entry allocated, Mask: L:0x0, R:0x80000000,RVTEP: , ESI: NULL ESI,Error: No error: 0, EntFlags: in_hash,in_ifd,in_ifl,in_vlan,in_rtt,in_ifbd,in_rmac, SM: GET_MAC, ALLOCATE_MAC, GET_IFD, GET_IFL, GET_IFBD, GET_RTT, GET_BD, ADD_TO_GLOBAL_DB, ADD_TO_IFD_LIST, ADD_TO_IFL_LIST, ADD_TO_IFBD_LIST, ADD_TO_RTT_LIST, ADD_TO_BD_LIST, ADD_TO_KERNEL, STOP, , CtxFlags: None , Actions: EVENT_POST, IN_SM, , actions:0x1000040, entry_addr:0x57d5410, ctxt_flags:0x0, ctxt_ext_flags:0x0, ent_flags:0x1002001f, ent_ext_flags:0x0, seq:2, gbp tag value:0,
In summary, if you need MAC addresses from single‑homed hosts to be replicated via ICCP so that both MC‑LAG peers remain synchronized—and at the same time allow those hosts to communicate with devices connected through MC‑AE interfaces—the VLAN must be included on at least one MC‑AE interface. This ensures it is treated as an "MC‑AE" VLAN and replicated accordingly.
For more information about MC‑LAG architecture, please visit: https://www.juniper.net/documentation/us/en/software/junos/mc-lag/topics/topic-map/getting-started-mc-lag.html