ge4 interface intermittently responds to ARP with physical port MAC instead of configured MAC — USG

AlePironiSerchim

Good question — let me break this down into what I've confirmed vs. what I'm inferring.

Confirmed physical connections:

• The fiber from our ISP terminates at a Cisco device (media converter/ONT), which connects via Ethernet to switch Port48.
• Switch Port46 connects to ge1 (p1) on the FLEX (confirmed via LLDP).

I don't have direct proof of a dedicated internal link between Port48 and Port46 specifically, but I compared their bandwidth utilization graphs over the same time period, and they show matching traffic spikes (same timing, similar shape/magnitude) — good indication that traffic does flow from Port48 through to Port46 toward the router, even without an exclusive point-to-point connection between just those two ports.

Separate finding: while investigating this, I noticed Ports 45 (LAN/ge4), 46 (WAN/ge1), and 48 (ISP-facing) are all configured identically on the switch as "Trunk port, PVID 1, Allowed VLANs: All" — no VLAN isolation between any of them. So the traffic correlation I'm seeing between 46 and 48 is consistent with normal switching within that shared, unsegmented broadcast domain, rather than a dedicated link. Not sure if this is relevant to the MAC issue, but wanted to flag it.

Mk88_it

https://community.zyxel.com/en/discussion/comment/86398#Comment_86398

@alessandropironi I don't think this configuration is in line with best practices. I would suggest modifying the configuration of the ports 46/48 in Access and with a new PVID that isn't used by any other ports.

FYI: Nebula VLAN - PVID Explained – Zyxel Support Campus EMEA

AlePironiSerchim

@Mk88_it

Thanks, that's good advice and I agree it's the cleaner approach. 
I'll keep this in mind as a follow-up improvement, but I'd rather not touch the switch config further right now while the main MAC/ARP issue is still open — want to avoid introducing additional variables until that's resolved.

Thank you.

PeterUK

It not a case of physical cabling issue but the VLAN setup for them ports on the switch

Mk88_it

https://community.zyxel.com/en/discussion/comment/86409#Comment_86409

Exactly, @AlePironiSerchim I think that the suggested vlan configuration is needed to solve the issue

Zyxel_Judy

Hi @AlePironiSerchim ,

If deployment allows, we recommend connecting the Cisco ONT directly to Port 1 (WAN) on the USG FLEX 100H, bypassing the switch for that link.

If there's a physical constraint that requires connecting the Cisco ONT through the switch as you've described, please configure Port 46 and Port 48 on the switch with a separate VLAN, so that ISP/WAN traffic no longer shares the same untagged VLAN 1 as your LAN traffic.

How to setup Nebula Switch VLAN configuration? — Zyxel Community

AlePironiSerchim

@PeterUK @Mk88_it you were both right, creating a new VLAN solved the issue. Thank you all and thank you @Zyxel_Judy , you saved my day.

Zyxel_Judy: connecting directly CISCO to the firewall is something I (and Claude AI to be honest that is helping me in troubleshooting) already thought about. I'll give a try as soon as possible, but I can clearly state that the problem is anyway solved.

AlePironiSerchim

One more thing worth flagging, even though the issue is resolved: I still believe there's a genuine firmware defect underneath this. ge1 (WAN1, subnet 62.94.250.235/29) was answering ARP broadcast requests for 192.168.1.1 — an IP that doesn't belong to its subnet at all. A correctly-behaving WAN interface should ignore ARP requests for IPs outside its own configured subnet, regardless of whether the broadcast physically reaches it. Creating the new VLAN just stopped that broadcast from reaching ge1 in the first place — it masked the trigger rather than fixing the underlying behavior.

So for anyone else who ends up in a topology where WAN and LAN interfaces briefly share a broadcast domain (migration, misconfig, shared uplink like ours), this could resurface. Might be worth a look on Zyxel's end even though our specific case is closed.

Anyway, thank you all again

Zyxel_Judy

Hi @AlePironiSerchim ,

We've also reproduced this symptom, and the fix will be included in the next official firmware release. That said, we'd like to note that normal network deployments should not encounter this problem.