Restoring Config onto different unit - odd results

What does the output say from the restore of the config on bigip3?

 

 

H

I have the exact same setup but ConfigSync.pl was not sufficient because we want to replicate things that are in bigip_base.conf. i.e. VLANs and interfaces which in our env are plentiful and changing enough that we'd rather just have them synced to DR.

 

 

We backup our configs off the device anyway so in a DR event we will restore the entire UCS config to our DR device. Our plan looks something like this:

 

 

1. SCP UCS from backup location to DR device

 

2. SSH to AOM address an run hostconsh

 

3. Restore the UCS to the DR box

 

b config install /path/to/config.ucs

 

4. Change the management IP back to what it is supposed to be

 

b mgmt 10.10.10.10 { netmask 255.255.255.0 }

 

b mgmt route default inet { gateway 10.10.10.1 }

 

5. Fix the hostname

 

b system { hostname our.f5.example.com }

 

6. Make the unit into a stand alone unit

 

b failover redundant disable

 

7. Test

 

8. Extinguish any hair that is on fire

 

 

The only thing we are considering doing to make it more automatic is to make sure that a copy of the config from UNIT 1 in the production HA pair is copied automatically to the DR unit. The reason we haven't is because the box we use to connect to the DR unit is the same box we keep the backups on. So if we can't get to that we can't do much anyway. I supposed if the backup were on the DR unit someone could console the F5 to get it up.

 

 

Hope this helps.

 

 

-Alan

 

Here's what shows up when I do this via command line:

 

 

 

[root@bigip3:Active] ucs b config install bigip2_full.ucs

 

Saving active configuration...

 

Current configuration backed up to /var/local/ucs/cs_backup.ucs.

 

Product : BIG-IP

 

Version : 10.2.2

 

Hostname: UCS : bigip2.winndixieus.wd.com

 

System: bigip3.winndixieus.wd.com

 

Installing --shared-- configuration on host bigip3.winndixieus.wd.com

 

Installing configuration...

 

Post-processing...

 

Reading configuration from /config/low_profile_base.conf.

 

Reading configuration from /defaults/config_base.conf.

 

Reading configuration from /config/bigip_sys.conf.

 

Reading configuration from /config/bigip_base.conf.

 

Reading configuration from /usr/share/monitors/base_monitors.conf.

 

Reading configuration from /config/profile_base.conf.

 

Reading configuration from /config/daemon.conf.

 

Reading configuration from /config/bigip.conf.

 

Reading configuration from /config/bigip_local.conf.

 

Loading the configuration ...

 

[root@bigip3:Standby] ucs

 

 

 

Even though it says it installed the shared configuration, all the Self-IPs on bigip3 are identical to bigip2, and it thinks it's part of an HA pair.

 

That makes sense since you are restoring the config from bigip2. The UCS from bigip2 will contain the bigip_base.conf from bigip2 which will only have its own self-ips in it.

 

 

Try restoring a config from bigip1 and then running "b failover redundant disable". This will make the unit think its a standalone instead of a member of a HA pair.

 

 

Another option if you are really only concerned about the shared parts of the config is to use something like

 

 

bigip2 b export oneline | grep -e "^\(node\|monitor\|virtual\|pool\)" > /var/tmp/shared.conf

 

bigip2 scp /var/tmp/shared.conf bigip3:/var/tmp/shared.conf

 

 

bigip3 b config save /var/tmp/bigip3_full.ucs

 

bigip3 b merge /var/tmp/shared.conf

 

 

The bigpipe merge command is like import but instead of replacing the whole config it merges it with the config provided.

 

 

Regards,

 

-Alan

One thing that occurs to me now that I look at it again is that using export | merge is that this does not take into account deletions on bigip2.

 

 

If any virtual services/pools etc are deleted from bigip1/2 they won't be deleted as part of the export | merge. You'd have to remember to manually delete them from bigip3. If your setup is really pretty constant though this might not be a problem for you.

 

 

We on the other hand have a pretty dynamic config so the UCS restore with a few fixes is a better solution for us.

 

 

-Alan

 

Hmmm.. If I were to do this, would it be a problem running this again and again? Would I need to restore the config of bigip3 to a previous state before each merge?

 

 

Did you get some of the above from another article/site? If so, can you link it here? Looking for more details, as this looks promising.

 

I do not believe I got it from an article or a site. I learned about bigip merge when we had to split one device into two, or rather one HA pair into two. We used 'b export oneline' and just picked out what we needed to take off one LB and put on the other.

 

 

As for running it repeatedly I don't think it would be a problem. How automated is your DR process? Will human hands be involved in cutting over to your DR site? Maybe you can just periodically export the config and copy it to bigip3 and then during a DR event apply the config.

 

 

Along those lines it might be wise to keep a copy of the UCS from bigip1 or bigip2 available during a DR scenario anyway. That way if you've forgotten something you can at least get it from the config.

 

 

Regards,

 

-Alan