Configuring HA (High Availability)

are you sure? the naming system is ...from version...to version...

Got it. Missed the obvious. Downloaded the version and uploaded/installed successfully. Now both primary and backup box are on same Up2Date firmware versions.

Then did factory reset from backup box's WebAdmin menu. Rebooted it from cold start. Configured HA for automatic on primary box.  Connected network cable to ETH2 on primary to ETH2 on slave. Getting good connectivity lights. 

Now getting this in the HA live log:

2015:10:21-01:34:55 ddpnet ha_zeroconf[16059]: id="3800" severity="info" sys="System" sub="ha" name="Waiting for interface to come up..."

2015:10:21-01:34:55 ddpnet conntrack-tools[32436]: no dedicated links available!

2015:10:21-01:34:58 ddpnet conntrack-tools[32436]: no dedicated links available!

2015:10:21-01:38:08 ddpnet ha_zeroconf[16059]: id="3800" severity="info" sys="System" sub="ha" name="Shutting down"

2015:10:21-01:38:09 ddpnet conntrack-tools[32436]: no dedicated links available!

2015:10:21-01:46:52 ddpnet ha_zeroconf[3783]: id="3800" severity="info" sys="System" sub="ha" name="Interface eth2 is up! Searching for active HA system!"

2015:10:21-01:46:52 ddpnet ha_zeroconf[3783]: id="3800" severity="info" sys="System" sub="ha" name="Using temporary ip 198.19.250.150"

2015:10:21-01:46:59 ddpnet ha_zeroconf[3783]: id="3800" severity="info" sys="System" sub="ha" name="No HA active, trying asg zeroconf!"

2015:10:21-01:47:24 ddpnet ha_zeroconf[3783]: id="3800" severity="info" sys="System" sub="ha" name="No other asg zeroconf node found!"

2015:10:21-01:47:24 ddpnet ha_zeroconf[3783]: id="3800" severity="info" sys="System" sub="ha" name="Waiting for interface to come up..." 

Configured HA in Hot/Standby mode.  Save Primary a name and node ID and a passphrase.  Saved settings. Rebooted slave.  HA ports on units lit up with good lights on bootup of slave, but then go dark. Link status is "down" on Primary dashboard.

Now all I see in HA status tab is this (screen attachment). Okaaay. Im out of ideas.  

If the factory reset did not reset the HA mode to automatic, Im going to literally jump out of my bedroom window.

I know Automatic should work, but I prefer to configure Hot-Standby in the Master instead.  Once you've done that, factory reset the Slave again if the Master doesn't show syncing immediately.

Cheers - Bob

OK I **think** I finally have it working now.  I changed Primary to Hot/Standby and configured the node name, passphrase etc.

I noticed I was getting routing issues throughout the day. Just slow intermittent issues. Since HA wasnt working properly I figured it may be the Slave on the network with the same 192.168.0.1 IP and since its not working in HA Slave mode, its just mucking up the routing.

So..you guessed it..had to remove the Primay SG125 from the network so I could see if I could still talk to a x.x.0.1 address and of course I could which was the backup SG125. Logged into it to see how the HA was set in it since I did a recent FACTORY RESET.

Well, low and behold the HA was set to "Automatic" which is fine, but the NIC was reset to ETH03.  I said ETHERNET 3.  Have no idea how this was done because I never did it. Does the factory reset this to ETH3 instead of ETH2???  So for the last couple days of troubleshooting I was basically the HA to a dark port on ETH02.

So I set the backup SG125 HA port to ETH02 and doublechecked that my manual firmware update done a cpl days ago was indeed 9.350-12 like the primary. Then pulled backup SG125 off network and put primary SG125 back on network. Logged into primary and turned off and set up HA mode again as Standby just for grins.

Then grabbed my 6 inch cat-5 cable and replugged the two ETH02 HA ports together.  Got good lights. Checked HA live log and got this:

2015:10:21-23:06:08 ddpnet-1 ha_daemon[27469]: id="38A0" severity="info" sys="System" sub="ha" seq="M: 43 08.715" name="Reading cluster configuration"

2015:10:21-23:06:23 ddpnet-1 ha_daemon[27469]: id="38A0" severity="info" sys="System" sub="ha" seq="M: 44 23.655" name="Clear syncing.files for node 2"

2015:10:21-23:06:23 ddpnet-1 ha_daemon[27469]: id="38A0" severity="info" sys="System" sub="ha" seq="M: 45 23.877" name="Monitoring interfaces for link beat: eth1 eth0"

2015:10:22-05:06:30 ddpnet-2 repctl[14697]:  stop_backup_mode(664): stopped backup mode at 000000010000000100000038

2015:10:22-05:06:30 ddpnet-2 repctl[14697]:  execute(1627): waiting for server to start....

2015:10:22-05:06:31 ddpnet-2 repctl[14697]:  execute(1627): done

2015:10:22-05:06:31 ddpnet-2 ha_daemon[14595]: id="38A0" severity="info" sys="System" sub="ha" seq="S: 42 31.194" name="HA control: cmd = 'sync stop 1 database'"

2015:10:22-05:06:31 ddpnet-2 ha_daemon[14595]: id="38A0" severity="info" sys="System" sub="ha" seq="S: 43 31.194" name="Deactivating sync process for database on node 1"

2015:10:22-05:06:31 ddpnet-2 repctl[14697]:  setup_replication(229): checkinterval 300

2015:10:22-05:06:49 ddpnet-2 ha_daemon[14595]: id="38A0" severity="info" sys="System" sub="ha" seq="S: 44 49.693" name="Monitoring interfaces for link beat: eth1 eth0"

2015:10:22-05:07:03 ddpnet-2 conntrack-tools[15104]: flushing kernel conntrack table (scheduled)

2015:10:22-05:10:46 ddpnet-2 ha_daemon[14595]: id="38A0" severity="info" sys="System" sub="ha" seq="S: 45 46.800" name="Initial synchronization finished!"

2015:10:22-05:10:46 ddpnet-2 ha_daemon[14595]: id="38A0" severity="info" sys="System" sub="ha" seq="S: 46 46.801" name="state change SYNCING(2) -> ACTIVE(0)"

2015:10:21-23:11:01 ddpnet-1 ha_daemon[27469]: id="38A0" severity="info" sys="System" sub="ha" seq="M: 46 01.619" name="Node 2 changed state: SYNCING(2) -> ACTIVE(0)"

2015:10:22-05:22:25 ddpnet-2 ha_daemon[14595]: id="38A0" severity="info" sys="System" sub="ha" seq="S: 47 25.876" name="Reading cluster configuration"

2015:10:22-05:22:30 ddpnet-2 ha_daemon[14595]: id="38A0" severity="info" sys="System" sub="ha" seq="S: 48 30.972" name="Monitoring interfaces for link beat: eth1 eth0"

2015:10:21-23:56:01 ddpnet-1 ha_daemon[27469]: id="38A0" severity="info" sys="System" sub="ha" seq="M: 47 01.149" name="Executing (wait) /usr/local/bin/confd-setha mode master master_ip 198.19.250.1 slave_ip 198.19.250.2"

2015:10:21-23:56:01 ddpnet-1 ha_daemon[27469]: id="38A0" severity="info" sys="System" sub="ha" seq="M: 48 01.450" name="Executing (nowait) /etc/init.d/ha_mode check"

2015:10:21-23:56:01 ddpnet-1 ha_mode[32602]: calling check

2015:10:21-23:56:01 ddpnet-1 ha_mode[32602]: check: waiting for last ha_mode done

2015:10:21-23:56:01 ddpnet-1 ha_mode[32602]: check_ha() role=MASTER, status=ACTIVE

2015:10:21-23:56:01 ddpnet-1 ha_mode[32602]: check done (started at 23:56:01)  [/CODE]



So I think all the statuses on the primary SG125 HA tab are looking good now and this log appears as it should? Both boxes now on same current firmware. Both connected to LAN and WAN. Both daisy chained on ETH02 HA ports.



I have the primary set up as Preferred Master just so whenever its back online its the main active firewall box.



Based on what you see, did I solve the riddle? Fingers crossed! Thanks for ongoing help. I may end up writing a forum tutorial on this to help the next guy avoid all my dead ends.

In my experience, setting a preferred master has resulted in problems during Up2Dates.  With two identical appliances, there's no reason to prefer either unit.

Cheers - Bob

Bob-
In HA mode, are both boxes indeed 101% identical? If the master goes down, the slave has all the licensing installed, settings, firmware, etc, etc?

So then when the Master comes back up, the slave updates the master with any new settings?  Does the slave then become the Master in perpetuity until the Slave goes down?

 If the master goes down, the slave has all the licensing installed, settings, firmware, etc, etc

The settings and licensing are the same after syncing.  Firmware is not automatic and both boxes have to be on the same version to sync.

So then when the Master comes back up, the slave updates the master with any new settings? Does the slave then become the Master in perpetuity until the Slave goes down?

You have UTM1 and UTM2, with UTM1 being the Master.  UTM1 goes down, UTM2 will become the Master and when UTM1 comes back up, it will be the Slave.  The system with the longest uptime gets to be the Master.