Skip to main content

Hello all!

 

This post is more of a PSA regarding the latest version of the Veeam hardened repo community ISO provided by Rick Vanover on June 29th of 2023. If you’ve noticed weird network issues while setting up multiple repos on the same network using this ISO, this may help you.

 

While working on setting up two repositories on the same network, I ran into a weird network issue where only one repository seemed to be communicating at a time, noticed after running a ping to both at the same time and seeing only one was responding at any given time. After further troubleshooting, what I noticed is that both machines had generated the same software-defined MAC address for 802.3ad bonds. This MAC address is usually uniquely generated from the machine-id to avoid conflicts, but when digging deeper I noticed that both servers also had the same machine-id.

 

It seems that the machine-id may be baked into the ISO and as a result, any machines we installed using this ISO ended up generating the same MAC address and conflicting on the local network. Over 8 different installs, 6 physical and 2 virtual, it seems that each one had the same /etc/machine-id file. 

 

To get around this issue, I regenerated the machines’ id’s using the following commands, which successfully changed their IDs to be unique and gave them nonconflicting MAC addresses:

  • rm -f /etc/machine-id
  • dbus-uuidgen --ensure=/etc/machine-id

I used these commands on machines that had already been deployed from the ISO and added to Veeam Backup & Replication using a console and didn’t have any problems, but I would recommend doing this during the initial install process and before you add it to VBR to avoid any SSH key issues.

 

 

TLDR; if you’re having weird network issues with multiple repos on the same network using the June 29th 2023 Community ISO for Veeam’s Hardened Repository, you may want to ensure that the machine-id is unique on each of them, otherwise you could run into conflicting MAC addresses.

 

Hope this helps someone!

This is one of the reasons we also pulled it.


On the post @Rick Vanover had made it clear that the ISO was only for test environments not production environments.
Was a quick deployment to see what happened by applying DISA STIG policy.


Interesting it happened on physical machines, but the OS is installed by the ISO as well as hardened deployment and configs, so kinda makes sense.

@Rick Vanover ...ping’ing you here so you’re aware. I know “something” (an update?) to the ISO is coming soon...like maybe at VeeamON. Thought you should be aware of this issue if you weren’t already.


That seems interesting that it would be embedded in the ISO when installing as I have never noticed this when using it for deployments but now makes me want to go back and check the servers.  Thanks for sharing this and hopefully the new ISO addresses many things including FC storage being connected and the installer constantly crashing.


Still standing by for the re-release of the ISO, but patiently at least.  😀


Comment