We have three BIG-IP LTM's. Two are running in an HA pair at our main datacenter (bigip1 and bigip2) and a third unit is at our DR site (bigip3).
I've been using the ConfigSync.pl script to try to download the config of one of the HA pair and load it onto the standalone unit at our DR site. According to what I've read, this should leave the bigip_base.conf file in place on the unit at the DR site, since the host names are different. They both have the same VLANs and Route Domains configured, but I need to get all the Virtual Servers, Pools, etc. copied up. Since that's the part that changes regularly, I wanted to automate this so that bigip3 is kept in sync (within 24 hours or so) with the HA pair.
BUT, when I restored the config file from bigip2 onto bigip3, I got unexpected results. The management IP and hostname remain the same, but bigip3 suddenly thinks he is part of an HA pair and all bigip3's Self-IPs are replaced with the self-IPs from bigip2.
Shouldn't the self-IPs that were previously configured on bigip3 stay? Fortunately I had a backup of bigip3 taken just before this, so it was easy to correct.
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.
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
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.
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.
