Cerbo GX - Multiple MAC Addresses Detected on Network Switches

Hello,

I’m posting on behalf of the Port Authority of Santa Cruz de Tenerife (AP). We use the Cerbo GX in several of our DC power systems for monitoring and control.

We’re experiencing a network issue related to MAC address filtering on our switches. Our IT department configures the switches to allow only one MAC address per port — usually the Ethernet MAC of the Cerbo GX. However, the switches are detecting multiple MAC addresses from a single Cerbo GX device, and in some cases, even random or changing MAC addresses.

This is causing the switches to block the ports due to MAC security policies, which in turn disrupts system communication.

We’re trying to understand:

  • Why would the Cerbo GX be showing more than one MAC address?
  • Are there specific settings or interfaces (e.g., USB, WiFi, virtual interfaces) that might be contributing to this?
  • Is there a recommended configuration to ensure consistent network behavior and avoid port blocks?

Any help or insight from the community would be much appreciated!

Thanks in advance.

See here:

Or here

Thank you, this explanation clarifies the situation very well.

I now understand why the Cerbo GX announces two IP addresses, and that the link-local interface uses a randomly generated MAC address. However, in our network environment, strict MAC filtering policies are enforced, and having multiple MAC addresses from a single physical port is not acceptable.

Is there a way to permanently disable the link-local interface, so that only the MAC address of the physical Ethernet interface is broadcast and used for communication? We’d like to ensure that the Cerbo GX behaves like a traditional network device with a single, stable MAC address.

Looking forward to your guidance on whether this is possible and, if so, how to implement it.

Thanks again!

Range or mask filtering: Some professional networking equipment (e.g., Cisco with advanced MAC ACLs) allows you to block ranges or patterns of MAC addresses using wildcard masks. If you can identify a common pattern in the generated addresses (e.g., a specific OUI prefix), you could potentially block all addresses that match that pattern. However, if the randomization is complete, this method is unreliable.

Multiple MACs are not uncommon, can’t they add the MACs to an allowed ACL on the switches?

Thanks again for the follow-up.

We did consider monitoring the pattern of the random MAC addresses, but as they appear to be generated dynamically at each boot, we haven’t found a reliable or consistent pattern that could be used to whitelist them in advance. From a technical and operational perspective, this makes maintaining a secure and predictable network setup quite difficult.

We are indeed using HPE Aruba switches, which support MAC-based ACLs, but our IT policy only allows static, pre-approved MAC addresses per port. Dynamic or randomly generated MACs fall outside our accepted configuration standards, and unfortunately can’t be added manually each time they change.

This is why we’re still looking for a way to disable the link-local interface entirely or prevent it from assigning a secondary MAC address — ideally via a supported configuration or firmware setting.

If that’s not possible today, it might be worth considering as a feature request in future firmware updates, especially for users operating in enterprise-grade or security-sensitive environments.

Appreciate the insights and support from the community!

Hi

To resolve the issue you’re experiencing, I recommend setting a static IP address for your Cerbo’s. You can then bind each Cerbo’s MAC address to its corresponding IP address using strict MAC binding in your router/switch.
Filtering is then easy.

I use a draytek 3912 and this works well in this and my managed switches.

If remote access is needed, NAT Port Forwarding can be utilized.
Let me know if you have any questions.

EDIT
Port knocking can be turned on if worried about open ports.

Dave

Hi everyone,

Just wanted to follow up on the issue we were investigating with the Cerbo GX showing multiple MAC addresses on our network switch, even though it’s configured with a static IP on eth0.

After some digging, we noticed the system automatically creates a second interface called ll-eth0, which:

  • Gets a link-local IP address in the 169.254.x.x range
  • Has a different, randomly generated MAC address
  • Is visible to the switch — which causes alerts due to multiple MACs on a single port

We enabled SSH access to the Cerbo GX and connected to the OS to investigate further. From there, we identified the process responsible:

avahi-autoipd: ll-eth0

It looks like avahi-autoipd is being triggered (possibly by connman) when no DHCP is available, as a fallback mechanism.

We tried disabling link-local networking via /etc/connman/main.conf, but that didn’t stop the interface from being created.

So, as a test, we simply renamed the avahi-autoipd binary to prevent it from running:

mv /usr/sbin/avahi-autoipd /usr/sbin/avahi-autoipd.disabled

After rebooting, ll-eth0 no longer appeared — just the main eth0 interface with the correct MAC, and the static IP worked as expected. The switch now only sees one MAC, as it should.


:yellow_circle: Open question for the community:

Does anyone know if disabling avahi-autoipd like this could have unintended side effects in Venus OS?

We haven’t seen any issues so far, but we’re curious if there are internal features (like device discovery or VE.Bus communication) that might rely on it.

Appreciate any feedback or insights. Thanks!

2 Likes

Well done :+1:

1 Like