[Solved] How to create a "backup" router?

I have two identical routers (R1 & R2) with 19.07.4 installed on both. R1 is up 'n running and works just fine.
I would like to prep R2, so that if R1 goes down, I just need to swap the ADSL cable and I'm up and running again.

Planed Process
I had thought that I could take a backup of R1 (LuCI System | Backup/Flash | Generate Archive) and upload to R2. Change the IP address. Job done!

The Problem
I now know, that when the archive is uploaded to R2, the MAC address of R1 is also installed on R2 - Not Good - if you wish (as I do) to have both powered-up at the same time.

A Solution?
Is there an Official MAC changer of some sort that I can use after I have Uploaded the Archive to R2?
If not, what does LuCI Network | Interfaces | LAN Edit | Advanced "Override MAC address" do?

Regards, M.

Can you show the specific config you're referencing?

???

If there was a MAC somewhere, just omit that particular config, simple.

:confused: Ummmm...it changes a MAC...but as you see, one is not originally set.

2 Likes

Hi,

The archive from R1 is a *.tar.gz file containing (in my case) 5 sub dir & 38 files. Within this archive the string "mac" is found in 5 files.
I suspect that this archive should be considered a SET? I would be most surprised to find I should remove a single file and then expect the uploaded archive to be functional.

Regards, M.

So that means you won't show the config(s)?

I think the community would be familiar with the config backup file, just really need to see the config in question - if you actually want assistance.

I would be surprised too (it likely won't be functionally identical to R1); because that's not what I suggested.

No, you can add, remove, edit, append the files as you please then restore it back to the router.

And keeping the mac address of R1 sounds like a good idea if your ISP is locking the router mac.

2 Likes

No not at all. How do I attach a file?

Regards, M.

Just copy-paste the file contents in preformated text (the </> button)

1 Like

:confused: You don't need to attach any files, just paste the relevant "MAC text" from the uncompressed archive - and tell us whatever file its in. Simple.

Please use the </> button to post that output.

(Perhaps I should add and suggest that you not keep thinking of the config archive as a binary or something...it merely contains text files. :wink: You seem to be making this a struggle for yourself.)

BTW - I won't be opening any files posted.

1 Like

Okay first point understood.
Point two makes sense for the WAN interface. Although, I don't think changing the WAN MAC would be much of a problem for me. The ISP would expect users to have to replace their routers from time to time anyway. That is just something that they have to take into account?

However, I was thinking of the inward-facing MACs. What happens when a new image is loaded? I'm guessing that there must be some mechanism for generating a set of random MACs on a new install? Otherwise the world will be full of OpenWrt routers with the same MAC! Not that it is a problem with distributed networks but multiple OpenWrt's on the same network (like mine) it will be a problem?

Regards, M.

Does this post mean you do or don't have an issue with transferring the R1 config to R2...I'm lost now (and still see no config).

You just said your ISP doesn't, so no.

We still have no clue what config you're referencing. I don't think anyone who's responded to your posting thus far - is aware of a MAC config setup in OpenWrt by default.

2 Likes

the problem is you over-thought it...

the only issue is when you switch over... and downstream clients / switches need to age the old mac/ip combination... assuming you were quick enough / isolated enough to gain access to the alternate router before your client picked up it's new mac...

waiting a couple of minutes for to switch on a backup router... is generally acceptable to most...

duplicating the wan-mac on the hot swap device is not a problem...

what is a problem is basic network skills to use an alternate ip on the spare to gain access to it when not in use... or, knowing how to correctly isolate your client(s) / flush your arp table...

2 Likes

My apologies if I am not making myself clear. Let me try again non-verbally.
Duplicate_mac

Router_2 will remain connected after the archive has been uploaded (& IP changed).
Now I have been told that there is not a script to auto-generate a new MAC set, the only question is:

Do I just change the br-lan? Or is there a requirement to change all six (excluding dsl0 which will be updated by ISP) as a sequential set?

Regards, M.

It won't work like this.
You'll need to have the dhcp server of R2 disabled all the time and enable it when the R1 goes down. Then you'll have to renew dhcp address to all hosts after the R2 takes over the adsl, or keep the dhcp lease time to a minimum so that it can occur automatically. If you had two adsl lines you could try some first hop redundancy protocol. But in your case it makes more sense just to swap all cables from R1 to R2.

2 Likes

I'm not sure what all the fuss is about MAC. to be clear normally OpenWrt doesn't override any MAC addresses and you just have whatever the hardware MAC is.

There is a great piece of software called keepalived which uses VRRP and swaps the IP addresses and MAC addresses from one router to the other when connectivity fails.

However, are you using routers with built in ADSL modem? If so there is no way to avoid swapping the ADSL cable.

3 Likes

I don't wish to get into a flaming match with the experts but just in case any other newbies sees the above, it is NOT what I am seeing.
If I transfer /etc/config/network (via the LuCI archive/resore) the the br-lan MAC on the destination get changed. See the two right-hand boxes in above image. If the source and destination routers are on the same network at the same time the Loop Detection alarms sound.

I note that you use the caveat "normal". Maybe what I have been doing is not normal - which would not surprise me one bit!

Regards, M.

OpenWrt tries to use the factory-determined MAC address for ports since it should be globally unique. The factory stores the MAC somewhere in a reserved area of flash such as a "factory" partition that OpenWrt always treats as read-only. Part of developing OpenWrt for a model is to find where the MAC is stored and set up code to read it. The problem is that different manufacturers and different models store the MAC in different places and different ways.

In some cases OpenWrt will extract the factory MAC at runtime when the port is brought up-- but in other cases a firstboot script extracts it only once and creates a device section in /etc/config/network like this:

config device 'lan_eth0_1_dev'
	option name 'eth0.1'
	option macaddr 'b4:fb:e4:<redacted>'

Luci does not have a way to access this value. It is supposed to be an invisible process of how the per-unit MAC on the sticker gets to be the default for the port.

This config stanza is part of the runtime configuration and since the backup / restore process stores whole files without parsing anything in the files, it will propagate to restoring a backup onto a different unit.

Again this only applies to some models, others will not have a config device and will get the unit's factory MAC directly from the ROM.

Also this is completely separate from the per-interface override mac address. The "factory" MAC is a default value.

3 Likes

That's right, you maybe have added a MAC override by hand at some point? If you install a brand new fresh OpenWrt without keeping old settings this does not happen in any hardware I am aware of. Perhaps there are some exceptions but they are rare and would probably occur because the hardware is mildly broken.

some terminology for future readers...;

this would be hot-standby and not 'backup'...

powered-on with autofailover is closer to 'redundant' again not 'backup'

'backup' = cold standby

the 'flash config' approach is indicative of a cold-standby... hence mentioning... knowning when and how to isolate..

if you want warm standby or redundancy... this is not a 'flash duplicate' scenario... ( at least not in the way you envisage )

3 Likes

Almost all of the hardware failures I've had are from lightning strikes. Preparing for that means two conditions:

  • The spare unit should be kept in a safe place with nothing plugged into it.
  • The failed unit is probably never going to work again.

So duplicating the MAC is not a big deal.

2 Likes
  • You know there's software if you want both devices physically online

I see @dlakelan mentioned it.

Next:

  • If R1 failed, how will a file transfer take place?

(I'm still trying to understand why the OP never showed us were this so-called MAC config was.)