Product ManualXG-7100-1U
A CARP type Virtual IP address (VIP) is shared between nodes of a cluster. One node is master and receives traffic
for the IP address, and the other nodes maintain backup status and monitor for heartbeats to see if they need to assume
the master role if the previous master fails. Since only one member of the cluster at a time is using the IP address,
there is no IP address conflict for CARP VIPs.
In order for failover to work properly it is important that inbound traffic coming to the cluster (routed upstream traffic,
VPNs, NAT, local client gateway, DNS requests, etc) be sent to a CARP VIP and for outgoing traffic such as Outbound
NAT to be sent from a CARP VIP. If traffic is addressed to a node directly and not a CARP VIP, then that traffic will
not be picked up by other nodes.
CARP works similar to VRRP and HSRP, and may even conflict in some cases. Heartbeats are sent out on each
interface containing a CARP VIP, one heartbeat per VIP per interface. At the default values for skew and base, a
VIP sends out heartbeats about once per second. The skew determines which node is master at a given point in time.
Whichever node transmits heartbeats the fastest assumes the master role. A higher skew value causes heartbeats to be
transmitted with more delay, so a node with a lower skew will be the master unless a network or other issue causes the
heartbeats to be delayed or lost.
Note: Never access the firewall GUI, SSH, or other management mechanism using a CARP VIP. For management
purposes, only use the actual IP address on the interface and not the VIP. Otherwise it cannot be determined beforehand
which unit is being accessed.
2.3.2 Configuration Synchronization (XMLRPC)
To make the job of maintaining two practically identical firewall nodes easier, configuration synchronization is possible
using XMLRPC. Some areas cannot be synchronized, such as the Interface configuration, but many other areas can:
Firewall rules, aliases, users, certificates, VPNs, DHCP, routes, gateways, and more. As a general rule, items specific
to hardware or a particular installation, such as Interfaces or values under System > General or System > Advanced
do not synchronize. For a list of areas that will synchronize, see the checkbox items on System > High Avail Sync
in the XMLRPC section. Most packages will not synchronize but some contain their own synchronization settings.
Consult package documentation for more details.
When XMLRPC Synchronization is enabled, settings from supported areas are copied to the secondary and activated
after each configuration change.
XMLRPC Synchronization is optional, but maintaining a cluster is a lot more work without it.
2.3.3 State Table Synchronization (pfsync)
Active connection state information is exchanged between nodes using the pfsync protocol to achieve seamless
failover. When pfsync is active and properly configured, all nodes will have knowledge of each connection flowing
through the cluster. If the master node fails, the backup node will take over and clients will not notice the transition
since both nodes knew about the connection beforehand.
Failover can still operate without pfsync, but it will not be seamless. Without pfsync if a node fails and another takes
over, user connections would be dropped. Users may immediately reconnect through the other node, but they would
be disrupted during the transition.
2.4 Testing High Availability
With all of the configuration complete, the time has come for testing. Tests for each aspect of the system are listed
below. If any of the tests fails, review the configuration and consult Troubleshooting High Availability for assistance.
2.4. Testing High Availability 59
To Next Page
Loading...
