Should such a failure occur then the consequence is that both units will continue to function but they
will lose their synchronization with each other. In other words, the inactive unit will no longer have
a correct copy of the state of the active unit. A failover will not occur in this situation since the
inactive unit will realize that synchronization has been lost.
Failure of the sync interface results in the generation of hasync_connection_failed_timeout log
messages by the active unit. However, it should be noted that this log message is also generated
whenever the inactive unit appears to be not working, such as during a software upgrade.
Failure of the sync interface can be confirmed by comparing the output from certain CLI commands
for each unit. The number of connections could be compared with the stats command. If IPsec
tunnels are heavily used, the ipsecglobalstat -verbose command could be used instead and
significant differences in the numbers of IPsec SAs, IKE SAs, active users and IP pool statistics
would indicate a failure to synchronize. If the sync interface is functioning correctly, there may still
be some small differences in the statistics from each cluster unit but these will be minor compared
with the differences seen in the case of failure.
Once the broken sync interface is fixed, perhaps by replacing the connecting cable, synchronization
between active and inactive units will not take place automatically. Instead, the unsynchronized
inactive unit must be restarted after which the following takes place:
•
During startup, the inactive unit sends a message to the active unit to flag that its state has been
initialized and it requires the entire state of the active unit to be sent.
•
The active unit then sends a copy of its entire state to the inactive unit.
•
The inactive unit then becomes synchronized after which a failover can take place successfully if
there is a system failure.
Note: An inactive unit restart is required for resynchronization
A restart of the inactive unit is the only time when the entire state of the active unit is
sent to the inactive unit and this is the reason why a restart is required for
resynchronization.
11.2. HA Mechanisms
Chapter 11. High Availability
493
Summary of Contents for DFL-1600 - Security Appliance
Page 27: ...1 3 NetDefendOS State Engine Packet Flow Chapter 1 NetDefendOS Overview 27 ...
Page 79: ...2 7 3 Restore to Factory Defaults Chapter 2 Management and Maintenance 79 ...
Page 146: ...3 9 DNS Chapter 3 Fundamentals 146 ...
Page 227: ...4 7 5 Advanced Settings for Transparent Mode Chapter 4 Routing 227 ...
Page 241: ...5 4 IP Pools Chapter 5 DHCP Services 241 ...
Page 339: ...6 7 Blacklisting Hosts and Networks Chapter 6 Security Mechanisms 339 ...
Page 360: ...7 4 7 SAT and FwdFast Rules Chapter 7 Address Translation 360 ...
Page 382: ...8 3 Customizing HTML Pages Chapter 8 User Authentication 382 ...
Page 386: ... The TLS ALG 9 1 5 The TLS Alternative for VPN Chapter 9 VPN 386 ...
Page 439: ...Figure 9 3 PPTP Client Usage 9 5 4 PPTP L2TP Clients Chapter 9 VPN 439 ...
Page 450: ...9 7 6 Specific Symptoms Chapter 9 VPN 450 ...
Page 488: ...10 4 6 Setting Up SLB_SAT Rules Chapter 10 Traffic Management 488 ...
Page 503: ...11 6 HA Advanced Settings Chapter 11 High Availability 503 ...
Page 510: ...12 3 5 Limitations Chapter 12 ZoneDefense 510 ...
Page 533: ...13 9 Miscellaneous Settings Chapter 13 Advanced Settings 533 ...