Forum Discussion
JimS_43254
Nimbostratus
NimbostratusNetwork replacement system
I'm a semi-noob
We had our primary BIG IP LTM (version 10.2 build 1789) fail and the standby system (unit 2) properly took over. We received the new system and the hotfixes were applied to bring it to 1789. Unfortunately didn't have a proper saved ucs archive so we configured from scratch essentially duplicating the information from unit 2 except entering the unique IPs (external, internal, and peer) for unit 1.
Once unit 1 was configured it did not have any network connectivity to *anything* (except my laptop on the mgmt interface and serial console). It cannot ping the upline switch it is connected too or unit 2 or a mgmt box on the same internal network. I started over and stripped everything out of the configs. When the DB-9 cable connecting the two units is disconnected, unit 1 thinks its active also and can ping the mgmt box on both internal and external networks but still cannot talk to unit 2. Once the DB-9 is restored, unit 1 can again only talk to the laptop.
Also in the dynamic arp of unit 2, unit 1's peer interface show's up as: 10.1.1.4 ff:ff:ff:ff:ff:ff peer 0 RESOLVED
And because of the lack of connectivity I cannot ConfigSync unit 2 to the new unit 1
I'm overlooking something and I would appreciated any pointers and places to look to correct this
Thank you
7 Replies
Cspillane_18296Hello JimS,
this definately sounds like a config issue. You may wish to take an SCF backup from the working device (unit 2) with the command:
b export
which writes an SCF to /var/local/scf. SCP this file off, change the hostname, non-floating IP addresses, failover settings etc to be valid for unit 1.
Then load the file to /var/local/scf on unit 1 and make it active with:
b import
See if this makes any difference, you also then have a backup of the system in a single text file. An overview of SCF files is available here:
http://support.f5.com/kb/en-us/solutions/public/8000/400/sol8435.html
Let us know if this helps!
Chris
JimS_43254Awesome Chris! That worked perfectly. The system is running.
I had an import error cause by an iRule but I stripped all the iRules, pools, node, and VS info but then I had connectivity so I successfully could ConfigSync from the active system and all that info is now on the new system.
I have the one residual error. The new system is coming up active and with both active the network gets confused and I have to "force to standy". Trying to set the redundancy state preference to "standby" produces: 01070661:3: Attempt to enable both Failover.ForceActive and Failover.ForceStandby
Thanks!
Jim- hoolio
Cirrostratus
dupe... - hoolioHi Jim,
I generally don't use a failover state preference as it can lead to an additional, unnecessary failover when the preferred active unit fails, the peer becomes active and then the preferred active unit comes back online.
Aaron - JimS_43254So you would set the 2nd system to "None" in the failover preference? The unit will allow me to update the preference to None without an error where it gives an error with Standby. If that works then I won't have to be concerned during a reboot where both systems come up "active".
- hoolioIf one unit comes up and sees the other active, when both are set to a preferred state of none, the new unit should stay standby. I'd set both to none. If you're getting an error when setting a unit to a preferred state of none, I'd open a case with F5 Support. If you do, please report back on what you figure out for future reference.
Thanks, Aaron - JimS_43254I understand. Thank you.
The error was when trying to set the preference on the new unit 1 to "standby". There was no error when I set it to "none."
