Ether ports changing after SYSTEM/Reset Configuration

Following a [System/Reset Configuration] on an X86 baremetal (RouterOS 7.21.2), the ethernet port on the motherboard and the first ethernet port on the X520 SFP adapter will occasionally switch port number rendering the configuration script unusable without doing a search/replace on ether1 and ether2 every time.

For example, somedays the order of the ports is ether1 (motherboard), ether2 (X520 port 1) and ether3 (x520 port 2). Following a System/Reset Configuration, the order of the ports changes to ether1 (X520 port 1), ether2 (motherboard) and ether3 (x520 port 2).

Essentially, ethernet ports 1 and 2 will switch about every 6th System/Reset Configuration. How can I prevent this from happening ever again or perhaps a workaround?

Thank you,

I asked an AI and here are the answers. I’m posting the proposed solutions here in case it can help someone else in the future.

Here is the answer (PART 1) I got from the AI:

On MikroTik x86 systems (including CHR), interface names can swap after reboots because RouterOS assigns names based on the order the kernel detects the PCI devices, which isn't always consistent.

To fix this, you must bind the interface names to their MAC addresses using a script that runs on startup.

Steps to Lock Interface Names

  1. Identify your MAC addresses: Go to the Interfaces menu in WinBox and note the MAC address for each physical card.

  2. Create a Startup Script: Navigate to System > Scripts and add a new script (e.g., interface-fixer) with the following logic:

In a follow up question (PART 2), I asked to expand the script for LAN, WAN and MGMT ports.

To ensure your interfaces always map to the correct roles regardless of the boot order, we will create a script that checks every physical interface against a list of known MAC addresses and renames them accordingly.

Step 1: Map Your Hardware

First, identify the MAC addresses printed on your hardware or found in /interface ethernet print.

Desired Name MAC Address (Example)
WAN AA:BB:CC:11:22:33
LAN AA:BB:CC:44:55:66
MGMT AA:BB:CC:77:88:99

Step 2: The Logic Script

Go to System > Scripts in WinBox, create a new script named fix-interfaces, and paste the following code.

Note: This script uses a "temporary name" step. This prevents errors if you try to rename an interface to "WAN" while another interface is currently holding that name.

routeros

{
    # 1. Define your MAC-to-Name mapping
    :local mapping {"AA:BB:CC:11:22:33"="WAN"; "AA:BB:CC:44:55:66"="LAN"; "AA:BB:CC:77:88:99"="MGMT"}

    # 2. First pass: Rename interfaces to temporary names to avoid naming conflicts
    :foreach mac,name in=$mapping do={
        :local iface [/interface ethernet find where mac-address=$mac]
        :if ([:len $iface] > 0) do={
            /interface ethernet set $iface name=("temp-" . $name)
        }
    }

    # 3. Second pass: Set final names
    :foreach mac,name in=$mapping do={
        :local iface [/interface ethernet find where mac-address=$mac]
        :if ([:len $iface] > 0) do={
            /interface ethernet set $iface name=$name
        }
    }
    
    :log info "Interface names have been synchronized by MAC address."
}

Use code with caution.


Step 3: Automate at Boot

To ensure this runs every time the x86 hardware re-indexes the PCI bus, set up a scheduler task:

  1. Navigate to System > Scheduler.

  2. Click Add New.

  3. Name: apply-interface-fix.

  4. Start Time: startup.

  5. On Event: fix-interfaces (or paste the script code directly here).

  6. Policy: Ensure read, write, and test are checked.


Important Considerations

  • Existing Configurations: If you already have IP addresses, Firewall rules, or DHCP servers assigned to names like ether1, they will break once the name changes to WAN. You will need to update those references to point to the new names.

  • Virtual Environments: If you are running this on Proxmox or VMware, ensure the "Network Card" settings in the VM hardware use Static MAC addresses rather than dynamic ones.

In a follow up question (PART 3), I asked to expand the answer that the same CLI configuration files could be used on 2 different X86 RouterOS.

Step 1: Set the Identities

Run these commands on each respective router so the script knows which hardware it is currently running on.

  • Router 1: /system identity set name="R1"

  • Router 2: /system identity set name="R2"


Step 2: The Multi-Router Script

This script uses a conditional check to load the correct MAC address mapping based on the Router Identity.

routeros

{
    :local routerName [/system identity get name];
    :local mapping;

    # Define MAC mappings for each specific router
    :if ($routerName = "R1") do={
        :set mapping {"AA:11:11:11:11:11"="WAN"; "AA:22:22:22:22:22"="LAN"; "AA:33:33:33:33:33"="MGMT"}
    } else={
        :if ($routerName = "R2") do={
            :set mapping {"BB:11:11:11:11:11"="WAN"; "BB:22:22:22:22:22"="LAN"; "BB:33:33:33:33:33"="MGMT"}
        }
    }

    # Pass 1: Rename to temporary names (avoids "already exists" errors)
    :foreach mac,name in=$mapping do={
        :local iface [/interface ethernet find where mac-address=$mac]
        :if ([:len $iface] > 0) do={
            /interface ethernet set $iface name=("temp-" . $name)
        }
    }

    # Pass 2: Set final names
    :foreach mac,name in=$mapping do={
        :local iface [/interface ethernet find where mac-address=("temp-" . $name)]
        :if ([:len $iface] > 0) do={
            /interface ethernet set $iface name=$name
        }
    }
    
    :log info ("Interface names synchronized for router: " . $routerName)
}

Use code with caution.

Implementation Tips

  • Update MACs: Replace the placeholder AA:... and BB:... values with the actual MAC addresses for your two x86 boxes.

  • Scheduler: As before, ensure this script is added to the System Scheduler with the startup policy so it fixes the names immediately after a reboot.

  • Safety: If you have more than 3 interfaces, the unmapped ones will keep their default names (e.g., ether4).

Cheers!

I think this is where your AI is wrong. The script is only useful once, right after configuration reset (to be specified with /system/reset-configuration run-after-reset=...), to have the interface names that you want before other configurations are populated.

If you run it at every boot, when there are already other parts of the configuration that reference the interfaces' names, then the renaming does not do what you think it does. If you rename an interface, all references to it are immediately updated with the new name too! If you have a DHCP server instance configured on LAN for example, and for some reason your script renames the interface to WAN, then as are result, your DHCP server will still be configured on the same interface, that is now called WAN.

The renaming is only meaningful when the configuration is at the blank state.

I have no idea :astonished_face: how (if) a baremetal X86 has a "factory configuration" and if it is editable or replaceable with netinstall/whatever, I mean something like what you can see with:
/system default-configuration print

If it is possible, that would be where to insert the script to surely rename correctly the interfaces... :woozy_face:

But why do you need to constantly reset the system?...

Do something smarter than the use of Artificial Deficence(‡): Think on your own...

  1. Reset "until the order is right";
  2. Create a .backup;
  3. Done.

Every time you reload the backup, it will be as if it had just been reset, but it will still maintain the correct order...

‡: Although I, personally, would have liked to know the reason why this happens, before...

Very likely it is a "race condition" when connected devices (the ethernet port on the motherboard and the PCI network card) are enumerated, it could be both due to the way the Linux system underneath the RouterOS enumerates them or to some settings in BIOS/UEFI.

1 Like

That is exactly what’s happening at the kernel level. A race condition that impacts the ethernet port number assignment. I have 3 X86 baremetal RouterOS machines (2x DEV and 1x PROD) with the exact same hardware and they all exhibit this issue. My workaround over the years has been to find & replace the ethernet ports in the configuration file but there must be a proper documented workaround since I can’t be the first one to request assistance with this problem specific to the X86.

I have a reasonably complicated configuration file requiring 2 DEV X86 routers and a PROD X86 router. All changes start with a System/Reset Configuration, no default configuration, followed by a copy/paste of the new configuration in the terminal. A minor change requiring debugging can sometime require 5 or 6 system configuration reset which consequently triggers an ethernet port number assignment change.

On "normal" linux distributions, the problem was solved by udev device renaming ... and has been like that since (uh, I don't know?) 15 years ago. But that's a user-land service so for MT to resolve the same problem, they would have to implement (limited version of) same or similar solution.
I kinda doubt they will go into that since a) their own hardware hardly falls into the same pithole (routerboard devices only have single type of NICs while the problem occurs mostly if machine has NICs run by different drivers) ... and b) they are moving away from supporting bare-metal x86 installations (and the problem again doesn't occur on CHR as often ... or does it?).

Have you considered the solution I proposed to you?

How are you actually doing the reset?
Via (Winbox or Webfig in terminal)?

The normal command would be:
/system reset-configuration
that will reset the system by blanking the existing configuration and apply the default one.

But you can use:
/system reset-configuration no-defaults=yes

to NOT load the default configuration

And:
/system reset-configuration no-defaults=yes run-after-reset=myfile.rsc

to NOT load the default configuration AND apply a pre-made configuration

The myfile.rsc could contain some logic to assign the interface names to the right MACs.

While with "full" configurations importing a .rsc file may be problematic because of conflicts between the existing configuration and the one in the .rsc file, starting with no default configuration gives no issues.

My previous post was about the possibility (that cannot say if it applies to RouterOS on baremetal) to change (once and for all) the saved default configuration to the one containing the MAC name assigning logic, so that when resetting you only need to run the simple reset-configuration.

Or - as rextended suggested - restore a backup made immediately after a "right interface order boot".

RouterOS uses an internal database, not modifiable by GUI/CLI, which matches, in sequential order,
the default names to the real MAC addresses found.
But if it is x86 you can "easily" alter the files, but that's another story.

Artificially assigning names via script, based on the MAC address,
still causes the default names and database indexes to remain different than expected.
The "practical" solution is to simply reload the backup (of the same machine) made when, after the reset,
everything is in the correct/expected/wanted order.

Loading the backup is equivalent to resetting (done via command).

The only true and complete "reset" always remains netinstall, especially between different versions.

I thought that ROS feature to set interface name is exactly to solve this issue (similar to udev) and that interface names (configured ones) are bound in ROS contig to NIC HW address and it will be set to same names after reboot, even if default-name is different (set by enumerated order).