Configuring Failover

The following steps outline the process by which you configure DHCP failover. The remainder of this section describes the steps based on different site configurations.

1. Configure your DHCP server and duplicate its configuration to the backup server.

(a) Duplicate the configurations for scopes, policies, DHCP options, and IP addresses.

(b) If you have enabled Dynamic DNS updates on the main server, make sure that it is also enabled on the backup server. For more information about Dynamic DNS updates, see the "Configuring Dynamic DNS Update"chapter in this guide.

(c) If you are using reservations, make sure that reservations are configured identically on each server. For more information about creating reservations, see the "Making a Lease Available" section.

(d) If you are using client-class, configure both servers with identical client-classes. For more information about client-class, see the "Configuring Client-Class" chapter in this guide.

Give the scopes the same set of selection tags. For more information about scope selection tags, see the "Defining Scope Selection Tags" section.

Enter the clients in both clusters, or enter them in LDAP and direct both servers to the same LDAP server. For more information about using LDAP, see the "Configuring LDAP"chapter in this guide.

Note

By using the CLI, you can configure the main server interactively and then repeat the procedure on the backup server or you can place the configuration commands in a file and use that file to configure both the main and backup servers. The failover commands have been designed so that you can use the same set of commands to configure both the main and backup servers. For more information on using command files, see

nrcmd -b <FileA

2. Choose your backup configuration: simple, backoffice, or symmetric.

For simple, see the "Configuring a Simple Site" section.
For backoffice, see the "Configuring a Backoffice Site" section.
For symmetric, see the "Configuring a Symmetric Site" section.

3. Set up identical configurations on both servers.

4. Configure servers according to the choices made in Step 1.

5. Reload both servers. For instructions, see the "Configuring a Simple Site" section.

Note

6. If you are using BOOTP relays (IP helper address), configure all BOOTP relays to point to both servers. For instructions, see the "Configuring BOOTP Relays" section.

In all of the following examples, the main and backup servers have already been configured identically from a scope, policy, client, and client-class standpoint, and the server-wide default capabilities are used. These examples illustrate only the failover-specific configuration commands.

Note These example configurations are based on several different configurations. For a description of the ways that you can choose to set up main and backup servers, see the Network Registrar Concepts Guide.

C onfiguring a Simple Site

In Figure 10-1, there is a main server and a single backup server.

Figure 10-1: Simple Failover Configuration

Main Server:

Step 1 Enable failover for this DHCP server, by typing:

nrcmd> dhcp enable failover

Step 2 Specify the name of the backup server, by typing:

nrcmd> dhcp set failover-backup-server=backupserver.example.com

Step 3 Reload the server, by typing:

nrcmd> server dhcp reload

Backup Server:

Step 1 Enable failover for this DHCP server, by typing:

nrcmd> dhcp enable failover

Step 2 Specify the name of the main server, by typing:

nrcmd> dhcp set failover-main-server=mainserver.example.com

Step 3 Reload the server, by typing:

nrcmd> server dhcp reload

Sample Script

Instead of typing the nrcmd commands interactively, you could create a command file that you could run to configure both the main and backup servers.

dhcp enable failover
dhcp set failover-main-server=mainserver.example.com
dhcp set failover-backup-server=backupserver.example.com

System Defaults

You can change some of the system defaults, such as the number of leases that the main server should send to the backup server, or the maximum client lead time.

Note Whenever you change the system defaults you need to change them on both servers.

Main Server:

Change the poll interval---The poll interval is the interval that failover partners poll each other to confirm network connectivity. If you want to change this interval from the default of 10, type a command like the following:

nrcmd> dhcp set failover-poll-interval=14

Backup Server:

nrcmd> dhcp set failover-poll-interval=14

Note For more information about the properties that you can change, see the Network Registrar CLI Reference Guide. These properties and features all begin with the word failover.

Configuring a Backoffice Site

In Figure 10-2, there are several main servers and a single backup server. The main servers are Aserver and Bserver and the backup server is Cserver. The main servers have three scopes each: scope1, scope 2, and scope3 on Aserver, and scope4, scope5, and scope6 on Bserver.

Figure 10-2: Backoffice Failover Configuration

Main Aserver:

Step 1 Enable failover for this DHCP server, by typing:

nrcmd> dhcp enable failover

Step 2 Specify the name of the backup server, by typing:

nrcmd> dhcp set failover-backup-server=Cserver.example.com

Main Bserver:

Step 1 Enable failover for this DHCP server, by typing:

nrcmd> dhcp enable failover

Step 2 Specify the name of the backup server, by typing:

nrcmd> dhcp set failover-backup-server=Cserver.example.com

Backup Cserver:

Because you can only specify a single default main server, if you have more than one main server, you need to list the scopes of the other servers individually. The following example enables failover for each scope on the two main servers, and designates the main server for each scope.

Step 1 Enable failover for scope1, by typing:

nrcmd> scope scope1 set failover=scope-enabled

Step 2 Specify the name of the main server, by typing:

nrcmd> dhcp set failover-main-server=Aserver.example.com

Step 3 Repeat steps 1 and 2 for scope2 and scope3.

Step 4 Enable failover for scope4, by typing:

nrcmd> scope scope4 set failover=scope-enabled

Step 5 Specify the name of the main server, by typing:

nrcmd> dhcp set failover-main-server=Bserver.example.com

Step 6 Repeat steps 4 and 5 for scope5 and scope6.

Automatically Duplicating the Configuration on the Backup Server

Instead of typing the nrcmd commands interactively, you could create command files that enable you to duplicate the information about servers A and B to the backup server C.

Main Aserver:

Create a file for Aserver that contains all the information about the scopes and includes the following specifications for failover.

scope scope1 set failover=scope-enabled
scope scope1 set failover-main-server=Aserver.example.com
scope scope1 set failover-backup-server=Cserver.example.com
scope scope2 set failover=scope-enabled
scope scope2 set failover-main-server=Aserver.example.com
scope scope2 set failover-backup-server=Cserver.example.com
scope scope3 set failover=scope-enabled
scope scope3 set failover-main-server=Aserver.example.com
scope scope3 set failover-backup-server=Cserver.example.com

Main Bserver:

Create a file for Bserver that contains all the information about the scopes and includes the following specifications for failover.

scope scope4 set failover=scope-enabled
scope scope4 set failover-main-server=Bserver.example.com
scope scope4 set failover-backup-server=Cserver.example.com
scope scope5 set failover=scope-enabled
scope scope5 set failover-main-server=Bserver.example.com
scope scope5 set failover-backup-server=Cserver.example.com
scope scope6 set failover=scope-enabled
scope scope6 set failover-main-server=Bserver.example.com
scope scope6 set failover-backup-server=Cserver.example.com

On Aserver run the command file, by typing:

nrcmd -b <FileA

On Bserver run the command file, by typing:

nrcmd -b <FileB

On server C run the two command files, by typing:

nrcmd -b <FileA
nrcmd -b <FileB

Note In the case of a backoffice site, you could have enabled failover at the server level for the main server. If you enable failover at the server level, all scopes can engage in failover. If you disable failover at the server level, only those scopes that have enabled failover will be able to engage in failover activity.

Configuring a Symmetric Site

In Figure 10-3, there are two servers that share the network and the backup responsibilities. Aserver is the main server for scopes 1-3 and the backup server for scopes 4-6, and Bserver is the main server for scopes 4-6 and the backup server for scopes 1-3.

Figure 10-3: Symmetric Failover Configuration

Aserver:

Step 1 Enable main DHCP failover for this scope, by typing:

nrcmd> scope scope1 set failover=scope-enabled

Step 2 Specify the name of the backup server, by typing:

nrcmd> scope scope1 set failover-backup-server=Bserver.example.com

Step 3 Repeat steps 1 and 2 for scope2 and scope3.

Step 4 Enable backup failover by typing:

nrcmd> scope scope4 set failover=scope-enabled

Step 5 Specify the name of the main server, by typing:

nrcmd> scope scope4 set failover-main-server=Bserver.example.com

Step 6 Repeat steps 4 and 5 for scope5 and scope6.

Bserver:

Step 1 Enable failover for this scope, by typing:

nrcmd> scope scope1 set failover=scope-enabled

Step 2 Specify the name of the main server, by typing:

nrcmd> scope scope1 set failover-main-server=Bserver.example.com

Step 3 Repeat steps 2 and 3 for scope2 and scope3.

Step 4 Enable failover for this scope, by typing:

nrcmd> scope scope4 set failover=scope-enabled

Step 5 Specify the name of the backup server, by typing:

nrcmd> scope scope4 set failover-backup-server=Bserver.example.com

Step 6 Repeat steps 4 and 5 for scope5 and scope6.

Sample Script

The following script is for the symmetric server case in which Aserver is serving scopes scope1through scope3 as main, and Bserver is serving scopes scope4 through scope6 as main. They are backing up each other's scopes. You can use this script on both servers.

dhcp enable failover
scope scope1 set failover-main-server=Aserver.example.com
scope scope1 set failover-backup-server=Bserver.example.com
scope scope2 set failover-main-server=Aserver.example.com
scope scope2 set failover-backup-server=Bserver.example.com
scope scope3 set failover-main-server=Aserver.example.com
scope scope3 set failover-backup-server=Bserver.example.com
 
scope scope4 set failover-main-server=Bserver.example.com
scope scope4 set failover-backup-server=Aserver.example.com
scope scope5 set failover-main-server=Bserver.example.com
scope scope5 set failover-backup-server=Aserver.example.com
scope scope6 set failover-main-server=Bserver.example.com
scope scope6 set failover-backup-server=Aserver.example.com

Note If you have multiple interfaces on one machine, you must specify a host name that points to only one IP address or one A record. In other words, you cannot set up your servers for round robin support.

Using a Failover on a Multiple Interface Machine

If you plan to use failover on a machine with multiple interfaces, you must explicitly configure the local server's name or IP address. You can omit the name or IP address for the local server only if the machine has a single interface. For example, to configure Server A as main and Server B as backup in a situation in which each has only one interface, do the following:

Step 1 On Server A specify the name of the backup server:

nrcmd> dhcp set failover-backup-server=serverb

Step 2 On Server B specify the name of the main server:

nrcmd> dhcp set failover-main-server=servera

In this case, Server A assumes it is a main server because there is no configuration for a main server on Server A, while there is configuration for a backup server. Since Server A has only one IP address and name, it uses that interface and IP address to communicate with backup Server B.

But if Server A has multiple interfaces and multiple IP addresses (and presumably multiple DNS names, one per IP address and interface), then the situation becomes complicated. For example, Server A has two interfaces with these DNS names: servera and serverc. If you configured Server A like the above example, it would unpredictably choose a single interface from which to communicate with Server B. If it chooses the same interface configured on Server B as the main server (in the first example, servera), then failover initializes correctly. However, if it chooses serverc as the interface, failover does not initialize correctly.

You must explicitly name the interface on which you want Server A to communicate with backup Server B:

Step 1 On Server A, specify the backup server, as you did in the first example:

nrcmd> dhcp set failover-backup-server=serverb

Step 2 On Server A, specify the main server, giving it the same name as the interface configured on Server B as the main server:

nrcmd> dhcp set failover-main-server=servera

This procedure specifies which interface Server A uses to communicate with Server B and ensures that failover initializes correctly.

Configuring BOOTP Relays

Network Registrar's failover protocol works with all existing BOOTP Relay (also called IP helper) implementations. BOOTP relay is a router capability that supports DHCP clients that are not locally connected to a DHCP server. For more information about configuring routers, see the "Configuring Routers" section.

If you are using BOOTP relay, ensure that any BOOTP relay implementations point at both the main and backup servers. If they do not and the main fails, DHCP clients will not be serviced, because the backup server cannot see the required packets.

If you cannot configure the BOOTP relay implementation to forward DHCP broadcast packets to two different DHCP servers, configure the router to forward the packets to a subnet-local broadcast address for a LAN segment, which could contain both the main and backup DHCP servers. Then, ensure that both the main and backup DHCP servers are resident on the same LAN segment.

Supporting BOOTP Clients

You can configure scopes to support two types of BOOTP clients: static BOOTP clients and dynamic BOOTP clients.

Static BOOTP

Static BOOTP clients are supported using DHCP reservations. When you enable failover, remember to configure both the main and the backup server with identical reservations.

Dynamic BOOTP

Dynamic BOOTP clients are supported through the command scope enable dynamic-bootp. When you are using failover however, there are additional restrictions placed on the address usage in such scopes, because BOOTP clients are allocated IP addresses permanently and receive leases that never expire.

When a server, whose scope does not have dynamic-bootp enabled, goes to the PARTNER_DOWN state, it can allocate any available IP address from that scope, no matter whether it was initially available to the main or backup server. When dynamic-bootp is set however, the main server and backup servers can only allocate their own addresses. Consequently scopes that enable dynamic-bootp require more addresses to support failover.

When using dynamic BOOTP, do the following:

Segregate dynamic BOOTP clients to a single scope. Disable DHCP clients from using that scope with the scope name disable dhcp command.
Use the dhcp set failover-dynamic-bootp-backup-percentage value command to allocate a greater percentage of addresses to the backup server for this scope, as much as 50 percent higher than a regular backup percentage.

For more information about configuring dynamic BOOTP see the Network Registrar CLI Reference Guide.

Avoiding Configuration Mistakes

There are several ways to make a simple mistake and lose the DHCP redundancy provided by the failover protocol. Make sure that you have not made one of the following mistakes:

Enabled failover on one server and not on the other.
Configured main and backup servers differently, for example, fail to include some scopes in the backup's configuration.
Failed to configure the underlying network infrastructure, that is, fail to reconfigure all of your BOOTP relays to send DHCP packets to both main and backup servers.

In the first two situations, Network Registrar detects and logs the configuration mistakes during processing, although a mistake may be detected a considerable time after the actual misconfiguration occurred. However, Network Registrar cannot detect the mistake in the third situation.

You can only detect BOOTP configuration errors by performing live tests (akin to fire drills) in which you periodically take the main server out of service to verify that the backup server is available to DHCP clients.

Failover Operation

After you have configured failover, the Network Registrar DHCP servers automatically perform the following actions:

1. The main server and backup server initially connect.

2. The main server supplies information about all existing leases to the backup server.

3. The backup server requests a set of available addresses from the main server to use for new clients if the main server is out of contact with the backup server.

4. The main server provides a percentage of addresses from each scope to the backup server.

5. The backup server ignores all DHCP discovers (except renewals and rebindings) from DHCP clients unless it believes that the main server is down.

6. The main server updates the backup server whenever the main server performs an operation on behalf of a DHCP client.

Note While failover is in operation, clients can sometimes obtain leases whose expiration times are shorter than the amount configured. This is a normal part of keeping the main and backup server synchronized. Typically this will happen only for the first lease period after a client gets a lease, or when one or the other server is out of contact with its partner.

Handling Main Server Failure

In the event the main server fails, the backup server takes over and renews addresses of existing clients, and offers addresses to new DHCP clients.

When the main server returns from being down, it reintegrates with the backup server without administrator intervention. In this way, if the main server crashes and Network Registrar restarts the main server (or if the entire server crashes or undergoes a power loss, and then comes back) reintegration is automatic and seamless.

If the main server goes down for a long period or the backup server was allocated an unusually small percentage of leases when it first contacted the main server, the backup server may run out of addresses to offer to new clients.

Automatically Setting PARTNER-DOWN State

If you issue the dhcp enable failover-use-safe-period command, then in the absence of explicit actions after the failover safe period expires, the responding server goes into set PARTNER-DOWN state on its own. After you issue this command, there is no possibility of duplicate IP address allocation, if the partner server is down. If both servers go into partner down mode, then you can have duplicate IP addresses. For more information see the Network Registrar Concepts Guide.

Manually Setting PARTNER-DOWN State

If you do not issue the dhcp enable failover-use-safe-period command, on, you must manually set PARTNER DOWN. This allows the backup server to have access to all available address from the main server. Do the following:

1. Make sure that the main server is truly down.

2. Issue this command if you want the failover safe period to be 24 hours:

nrcmd> dhcp set failover-safe-period=24

3. Inform the backup server that the main server is down and give the backup server a time at which the main server ceased to operate by issuing the command server dhcp setPartnerDown.

After you issue this command, there is no possibility of duplicate IP address allocation.

Whichever method you use depends on your corporate policy.

If your corporate policy is to have minimal manual intervention, then use the failover-use-safe-period property. Unless there is a network problem, your operation should continue normally.

If your corporate policy is to avoid conflict under any circumstances, then you should never let the backup server go into PARTNER-DOWN state unless by explicit command. Allocate sufficient IP addresses to the backup server so that it can handle the arrival of new clients during periods when there is no administrative coverage. It is fairly simple to determine if the main server is down and to inform the backup server explicitly.

Maintaining Failover Servers

After you have configured failover, verify that failover is running correctly by checking the log files and running a report that displays information about the connection status of the main and backup servers.

When you check the log files for each server, note that there are two possible roles for each server with respect to every other server: it may be a main server for another server, or a backup server for another server. There is a failover object within the DHCP server for each of these roles, and the object name directly reflects its role.

In the simple configuration (see Figure 10-1), server A has one failover object, as main for Bserver and server B has one failover object, as backup for Aserver.
In the backoffice configuration (see Figure 10-2), each main server has one failover object, as main for Cserver, while server C has two failover objects, as backup for Aserver, and as backup for Bserver.

When the DHCP server configures itself, it logs every network that is part of each failover object. In addition, it reports the configuration parameters (such as the failover-maximum-client-lead-time, failover-backup-percentage, failover-user-safe-period state, and so on.). For more information about these parameters, see the Network Registrar CLI Reference Guide.

Monitoring Failover Operations

You can examine the DHCP server log files after you reload to verify your failover configuration. To change the amount of information reported in the log files pertaining to failover operation, do the following:

Using the CLI:

Set dhcp set log-settings failover-detail to increase the number and detail of failover messages logged.

: Reload the DHCP server for the changes to the log setting to take effect.
: To make sure previous messages do not get overwritten, append the failover-detail parameter to the end of the dhcp set log-settings command. For example:

nrcmd>dhcp set log-settings=default,incoming-packets,missing-options,failover-detail

Set server dhcp setDebug Y=1, to cause the failover-detail messages to take effect immediately.
Set server dhcp setDebug Y=2, to log more detailed failover messages.
Set server dhcp setDebug Y=3, to cause all messages logged for Y=1 or Y=2 to appear, as well as a formatted dump of each nonpoll failover packet.
Set server dhcp setDebug Y=4, to log all the poll messages, and generate logs of log messages (causing the log files to roll and log information to be quickly lost).

The settings Y=1, Y=2, and log-settings failover-detail do not load the server or add too much information to the log files. You can leave them on for all but the most heavily loaded servers.

Both Y=3 or Y=4 debug settings slow the server considerably, and should be used only when absolutely necessary. In particular, the Y=4 setting produces a large amount of output and should be used only when you need to verify that the server is communicating at the most basic level.

Using the GUI:

Step 1 Highlight the DHCP Server and right-click on Properties.

Step 2 In the DNS Server Properties dialog box, click the Advanced tab.

Step 3 In the Advanced dialog box, click Debug Settings.

Step 4 Click Enable Debug.

Step 5 In the Categories field, type Y = 1 (or 2, 3, or 4, depending on how detailed you want the messages to be).

Step 6 Select MLOG or Console,depending on whether you want your messages written to a log file or the console.

Step 7 Click Apply, then click OK twice.

Monitoring Failover Server Status

Run the dhcp getRelatedServers command to create a report about the connection status of the main and backup servers. You can run this command from the CLIor the GUI.

Table 10-1: getRelatedServers Report

Column Description

Type

Main, Backup, DNS, or LDAP

Name

DNS host name

Address

IP address in dotted octet format

Requests

Number of outstanding requests or two dashes (--) if not applicable

Communications

OK or INTERRUPTED

localhost State

Failover state of this server or two dashes (--)

Partner State

Failover state of the associated failover server or two dashes (--)

Column	Description
Type	Main, Backup, DNS, or LDAP
Name	DNS host name
Address	IP address in dotted octet format
Requests	Number of outstanding requests or two dashes (--) if not applicable
Communications	OK or INTERRUPTED
localhost State	Failover state of this server or two dashes (--)
Partner State	Failover state of the associated failover server or two dashes (--)

Changing Failover Server Roles

Be careful when you change the role of a failover server. Remember that all state information about IP addresses in a scope will be lost from a server if it is ever reloaded without that scope in its configuration.

Making an Existing Server a Main Server and Adding a New Backup Server

This is a way to update an existing installation and increase the availability of the DHCP service it offers.

Note You can only use this procedure if the original server never participated in failover.

Step 1 Install Network Registrar 3.0 on the original server and ensure that it operates correctly after the installation. For information about installation, see the Network Registrar Getting Started Guide.

Step 2 Install Network Registrar 3.0 on the machine that is to be the backup server. Note the machine's DNS name. For information about installation, see the Network Registrar Getting Started Guide.

Step 3 Enable failover on the original server. Use the DNS name of recently installed backup server. For more information see "Configuring a Simple Site" section.

nrcmd> dhcp enable failover
nrcmd> dhcp set failover-backup-server=backupserver.example.com

Step 4 Reload the main server. It should go into PARTNER-DOWN state and stay there, because it cannot locate the backup server (since the backup server is not yet configured). There should be no change in the operation of the main server at this point.

nrcmd> server dhcp reload

Step 5 Duplicate the main server's configuration on the backup server, including scopes (also secondary scopes), policies, client-class. If you are using client-class, make sure that the clients are entered into each cluster or that each server can access an LDAP database with the client information.

Step 6 Enable failover on the backup server.

nrcmd> dhcp enable failover
nrcmd> dhcp set failover-main-server=mainserver.example.com

Step 7 Reconfigure all of the operational BOOTP relays to forward broadcast DHCP packets to both the main and the backup server.

Step 8 Reload the backup server.

nrcmd> server dhcp reload

After you have completed these steps, the following incidents occur:

1. The backup server detects the main server and moves into RECOVER state.

2. The backup server refreshes its stable storage with the lease information that resides on the main server, and when complete, the backup server moves into RECOVER-DONE state when the MCLT (maximum client lead time) has been reached.

3. The main server moves into NORMAL state.

4. The backup server moves into NORMAL state.

5. The backup server uses a pool request to ask the main server for addresses to allocate if communications become interrupted.

6. After these addresses are allocated, the main server sends this information to the backup server.

Replacing a Failover Server That Has Lost Its Stable Storage

If a failover server loses its stable storage (that is, its hard disk), it is possible to replace the server and have it recover its state information from its failover partner.

Step 1 Determine which server lost its stable storage.

Step 2 Use the setPartnerDown command to tell the other server that its partner is down. If you do not specify a time, Network Registrar uses the current time.

nrcmd> server dhcp setPartnerDown other-server FEB 02 13:10 1999

Step 3 When the replacement server is operational, re-install Network Registrar.

Step 4 Duplicate the configuration from the original server to the replacement server.

Step 5 On the replacement server, set dhcp failover-recover time to approximately when the server failed.

nrcmd> dhcp set failover-recover "FEB 02 13:20 1999"

Step 6 Reload the replacement server.

nrcmd> server dhcp reload

After you have completed these steps, the following incidents occur:

1. The replacement server moves into RECOVER state.

2. The other server sends the replacement server all its information.

3. The replacement server moves into RECOVER-DONE state when the MCLT has been reached.

4. The other server moves into NORMAL state.

5. The replacement server moves into NORMAL state. The replacement server requests addresses, but few new ones are allocated, because the addresses previously allocated have been sent in step 2.

Note After the replacement server is in normal state, you must specify dhcp set failover-recover 0 and reload the replacement server.

Removing a Backup Server and Halting Failover Operation

Step 1 On the backup server, remove all of the scopes that were designated as backup to the main server. Repeat for each scope that you want to remove.

nrcmd> scope name delete

Step 2 On the main server, remove the failover capability from those scopes that were main for the backup server (or disable failover server-wide if that is how it was configured).

nrcmd> scope name set failover=scope-disabled
 
or
 
nrcmd> dhcp disable failover

Step 3 Reload the main server.

nrcmd> server dhcp reload

Step 4 Reload the backup server.

nrcmd> server dhcp reload

Adding a Main Server to an Existing Backup Server Serving Other Main Servers

Step 1 Duplicate the main servers scope, policy, etc., configuration on the backup server.

Step 2 Configure the main to enable failover and point to the backup.

nrcmd> dhcp enable failover
nrcmd> dhcp set failover-backup-server=backupserver.example.com

Step 3 Configure the backup to enable failover for the new scopes that point to the new main.

nrcmd> dhcp enable failover
nrcmd> dhcp set failover-main-server=mainupserver.example.com

Step 4 Reload both servers.

nrcmd> server dhcp reload

Network Registrar performs the same steps as those describe in the "Making an Existing Server a Main Server and Adding a New Backup Server" section.

Changing General DHCP Configurations

In the following cases, if you make any changes to your main DHCP server you must duplicate those changes to the backup server.

Adding, deleting, modifying scopes
Changing policies
Adding, deleting, modifying clients
Adding or changing IP addresses
Adding or changing reservations
Adding, deleting, modifying client-classes
Enabling or disabling dynamic DNS updates
Enabling or disabling dynamic BOOTP

Note Consider maintaining your entire DHCP server configuration in nrcmd command files and always make any changes to those files.

Importing Leases

Step 1 Stop the backup server.

nrcmd> server DHCP stop

Step 2 Enable import mode on the main server.

nrcmd> dhcp enable import-mode

Step 3 Reload the main server.

nrcmd> server DHCP reload

Step 4 Import the leases into the main server.

nrcmd> import leases filename

Step 5 Disable the import mode on the main server.

nrcmd> dhcp disable import-mode

Step 6 Reload the main server.

nrcmd> server DHCP reload

Step 7 Start the backup server.

nrcmd> server DHCP start

Exporting Leases

There are two ways that you can export lease information:

Use the nrcmd export leases command to export lease information about the state of all current and expired leases. This command does not identify the lease information as belonging to the main or backup servers.
Use the nrcmd export addresses command to export information about every address configured in every server that is specified in the configuration file. This includes addresses specified in DHCP scope ranges, DNS static addresses, and explicitly reserved addresses both for DNS and DHCP servers. Addresses in DHCP scope ranges that are not in use (allocated or reserved) however, do not appear in the output. The export addresses command also displays the failover role, if any.

Note For more information about the export leases and addresses commands, see the Network Registrar CLI Reference Guide.

Deactivating Leases

When DHCP safe failover is in use and you deactivate a lease with either the GUI or the CLI, it is deactivated only in the cluster to which you are connected. If you wish the lease to be deactivated on both the main and backup servers, you must connect to and deactivate the lease in each server's cluster.

Changing MCLT

Generally, if you have enabled failover on your DHCP server, you should not change the failover-maximum-client-lead-time (MCLT). If you must change the MCLT, do the following:

Step 1 Reload the backup server to ensure that all information that the backup server has to tell the main server is up-to-date on the main server. Ideally you should wait until the backup server and main server have stabilized, that is, both are in normal state, and any updates have been exchanged. At least wait until the backup server has completed its cache update process as noted in the log file.

nrcmd> server DHCP reload

Step 2 Change the MCLT on the main server. (Remember that any MCLT configured on the backup server is ignored by the backup server, because the backup server derives its MCLT value from directly from the main server.)

nrcmd> dhcp set failover-maximum-client-lead-time=4800

Step 3 Stop the backup server.

nrcmd> server DHCP stop

Step 4 Reload the main server.

nrcmd> server DHCP reload

Step 5 Start the backup server.

nrcmd> server DHCP start

Detecting and Handling Network Failures

How do you know that the servers are not communicating or that one server is down? It could be a network failure or a network partition, which means that the servers can communicate, but just not with each other. In this case, however, one server could really be down. Table 10-1 describes some symptoms, causes, and solutions for failover problems.

Table 10-2: Detecting and Handling Failures

Symptom Cause Solution

New DHCP clients fail to get IP addresses

A backup server that is in COMMUNICATIONS-INTERRUPTED state with too few IP addresses

Increase the backup percentage on the main server.

Error messages about mismatched scopes

Mismatched scope configurations between the main and backup servers

Reconfigure your servers.

Log messages about failure to communicate with partner

Partner cannot communicate with the other server

Main server fails. Some clients cannot renew or rebind leases and the leases expire despite the fact that the backup server is up and possibly processing some client requests.

Neglected to configure some BOOTP relay (ip-helper) to point at both servers

Reconfigure BOOTP relays to point at both main and backup server.

Run a fire drill test, that is, take the main server down for a day or so and see if your user community can get and renew leases.

SNMP trap: other server not responding

Partner cannot communicate with the other server

SNMP trap: dhcp failover config mismatch

Mismatched scope configurations between the main and backup servers

Reconfigure your servers.

Users complain that they are not getting access to the services they expect or that they are not able to use the system in the accustomed manner.

Mismatched policies and client-classes between the main and backup servers.

Reconfigure the servers to have identical policies. Possibly use LDAP for client registration if currently registering clients directly in main and backup servers.

Symptom	Cause	Solution
New DHCP clients fail to get IP addresses	A backup server that is in COMMUNICATIONS-INTERRUPTED state with too few IP addresses	Increase the backup percentage on the main server.
Error messages about mismatched scopes	Mismatched scope configurations between the main and backup servers	Reconfigure your servers.
Log messages about failure to communicate with partner	Partner cannot communicate with the other server
Main server fails. Some clients cannot renew or rebind leases and the leases expire despite the fact that the backup server is up and possibly processing some client requests.	Neglected to configure some BOOTP relay (ip-helper) to point at both servers	Reconfigure BOOTP relays to point at both main and backup server. Run a fire drill test, that is, take the main server down for a day or so and see if your user community can get and renew leases.
SNMP trap: other server not responding	Partner cannot communicate with the other server
SNMP trap: dhcp failover config mismatch	Mismatched scope configurations between the main and backup servers	Reconfigure your servers.
Users complain that they are not getting access to the services they expect or that they are not able to use the system in the accustomed manner.	Mismatched policies and client-classes between the main and backup servers.	Reconfigure the servers to have identical policies. Possibly use LDAP for client registration if currently registering clients directly in main and backup servers.

Using the DHCP Failover Configuration Tool

To ensure proper failover operation, both servers need to be identical. The DHCP Failover Configuration tool ensures that users can duplicate configurations without having to manually type the configurations on the backup machine, saving time and preventing errors. To accomplish this task, it uses the cnrFailoverConfig command.

The types of configuration options currently supported are:

Policy properties and dhcp-options
Scope properties and ranges
DHCP server properties

These configuration options are currently not supported:

Reservation lists
Client and client-class
Scope selection tags

The three main steps in the failover configuration process are the following:

1. Make a copy of the main server's configuration in the form of an nrcmd batch file, using the cnrFailoverConfig -clone command.

2. Pipe the nrcmd batch file to the backup server.

3. Check to make sure both servers are identical, using the cnrFailoverConfig -compare command.

The following sections explain these steps.

Step 1: Cloning the Main Server's Configuration

The following procedure shows how to clone the main server's configuration.

Step 1 Set up the main server's configuration.

Step 2 Save the configuration.

nrcmd> save

Step 3 Reload the main server.

nrcmd> server DHCP reload

Step 4 Create a clone file on the main server from the DOS command line.

C:\Program Files\Network Registrar> cnrFailoverConfig -clone -mc main_cluster_name -mu main_user_name -mp main_password -o output_filename

Table 10-3 describes the cnrFailoverConfig -clone commands.

Table 10-3: cnrFailoverConfig -Clone Commands

Command Description

-clone

Invokes the cloning operation.

-mc

Specifies the name of the main server.

-mu

Specifies the name of the user on the main server.

-mp

Specifies the password of the main user.

-o

Specifies the name of the output file.

Command	Description
-clone	Invokes the cloning operation.
-mc	Specifies the name of the main server.
-mu	Specifies the name of the user on the main server.
-mp	Specifies the password of the main user.
-o	Specifies the name of the output file.

Step 2: Piping the Batch File to the Backup Server

Perform these steps to pipe the batch file to the backup server.

Step 1 Switch to the backup server and pipe the batch file you created in the previous section to the backup server from the DOS command line.

C:\Program Files\Network Registrar> nrcmd -b < output_filename

Step 2 Save the configuration.

nrcmd> save

Step 3 Switch to the main server and reload.

nrcmd> server DHCP reload

Step 4 Switch to the backup server and reload.

nrcmd> server DHCP reload

Step 5 Wait a few minutes and issue the getRelatedServers command to verify that the two servers are in synch.

nrcmd> server DHCP getRelatedServers

For more information about this command, see the "Monitoring Failover Server Status" section.

Step 3: Comparing the Configurations of the Main and Backup Servers

Perform these steps to compare the configurations of the main and backup servers.

Step 1 Navigate to the window where you can display the configuration of the main server.

Step 2 Invoke the compare command from the DOS command line.

C:\Program Files\Network Registrar> cnrFailoverConfig -compare -mc main_cluster_name -mu main_user_name -mp main_password  -bc backup_cluster_name  -bu backup_user_name -bp backup_password -verbose -o output_filename

Step 3 Display the output file for discrepancies. Since configuration differences between the two servers are marked with the word "difference," you can search for that word within your text editor. Also, if you do not specify the -verbose switch, only the differences appear in the output file.

If there are differences, go back to the "Step 1 and correct the problem.

Table 10-4 describes the cnrFailoverConfig -compare commands.

Table 10-4: cnrFailoverConfig -Compare Commands

Command Description

-compare

Invokes the compare operation.

-mc

Specifies the name of the main server.

-mu

Specifies the name of the user on the main server.

-mp

Specifies the password of the main user.

-bc

Specifies the name of the backup server.

-bu

Specifies the name of the user on the backup server.

-bp

Specifies the password of the backup user.

-o

Specifies the name of the output file.

-verbose

Creates verbose output for the output file. If you do not specify this switch, the output is be summarized in a few lines, detailing only where the difference is found.

Command	Description
-compare	Invokes the compare operation.
-mc	Specifies the name of the main server.
-mu	Specifies the name of the user on the main server.
-mp	Specifies the password of the main user.
-bc	Specifies the name of the backup server.
-bu	Specifies the name of the user on the backup server.
-bp	Specifies the password of the backup user.
-o	Specifies the name of the output file.
-verbose	Creates verbose output for the output file. If you do not specify this switch, the output is be summarized in a few lines, detailing only where the difference is found.

Sample Output Files

The following sections contain sample output files from the cnrFailoverConfig -compare command.

Output File Without Errors

The following display shows an error-free sample output file created with the cnrFailoverConfig -compare command.

610 Compare global properties - main(sfo5) to backup(sfo6)
630 Global Ok - property 'failover': on
630 Global Ok - property 'failover-backup-percentage': 10
630 Global Ok - property 'failover-backup-server': sfo6
630 Global Ok - property 'failover-dynamic-bootp-backup-percentage': 
630 Global Ok - property 'failover-lease-period-factor': 1.50
630 Global Ok - property 'failover-main-server': sfo5
630 Global Ok - property 'failover-maximum-client-lead-time': 60m
630 Global Ok - property 'failover-poll-interval': 15s
630 Global Ok - property 'failover-poll-timeout': 60s
630 Global Ok - property 'failover-recover': Wed Dec 31 19:00:00 1969
630 Global Ok - property 'failover-safe-period': 24h
630 Global Ok - property 'failover-use-safe-period': disabled
611 Compare scope properties - scope(scope1) on main(sfo5) to backup(sfo6)
631 Scope Ok - scope(scope1) property 'addr': 123.123.123.0
631 Scope Ok - scope(scope1) property 'bootp': disabled
631 Scope Ok - scope(scope1) property 'deactivated': 
631 Scope Ok - scope(scope1) property 'dhcp': enabled
631 Scope Ok - scope(scope1) property 'dns-rev-server-addr': 
631 Scope Ok - scope(scope1) property 'dns-reverse-zone-name':
123.123.123.in-addr.arpa.
631 Scope Ok - scope(scope1) property 'dns-server-addr': 
631 Scope Ok - scope(scope1) property 'dns-zone-name': 
631 Scope Ok - scope(scope1) property 'dynamic-bootp': disabled
631 Scope Ok - scope(scope1) property 'dynamic-dns': disabled
631 Scope Ok - scope(scope1) property 'failover': use-server-settings
631 Scope Ok - scope(scope1) property 'failover-backup-server': 
631 Scope Ok - scope(scope1) property 'failover-main-server': 
631 Scope Ok - scope(scope1) property 'mask': 255.255.255.0
631 Scope Ok - scope(scope1) property 'ping-clients': disabled
631 Scope Ok - scope(scope1) property 'ping-timeout': 300
631 Scope Ok - scope(scope1) property 'policy': policy1
631 Scope Ok - scope(scope1) property 'primary-addr': 
631 Scope Ok - scope(scope1) property 'primary-mask': 
631 Scope Ok - scope(scope1) property 'primary-scope': 
631 Scope Ok - scope(scope1) property 'renew-only': 
631 Scope Ok - scope(scope1) property 'selection-tags': 
631 Scope Ok - scope(scope1) property 'synthesize-name': disabled
631 Scope Ok - scope(scope1) property 'synthetic-name-stem': dhcp
631 Scope Ok - scope(scope1) property 'trap-free-address-high': enabled
631 Scope Ok - scope(scope1) property 'trap-free-address-high-threshold': 
631 Scope Ok - scope(scope1) property 'trap-free-address-low': 
631 Scope Ok - scope(scope1) property 'trap-free-address-low-threshold': 
631 Scope Ok - scope(scope1) property 'update-dns-first': disabled
631 Scope Ok - scope(scope1) property 'update-dns-for-bootp': 
631 Scope Ok - scope(scope1) property 'Rangelist': {2071689985 2071690004}
611 Compare scope properties - scope(scope2) on main(sfo5) to backup(sfo6)
631 Scope Ok - scope(scope2) property 'addr': 124.124.124.0
631 Scope Ok - scope(scope2) property 'bootp': disabled
631 Scope Ok - scope(scope2) property 'deactivated': 
631 Scope Ok - scope(scope2) property 'dhcp': enabled
631 Scope Ok - scope(scope2) property 'dns-rev-server-addr': 
631 Scope Ok - scope(scope2) property 'dns-reverse-zone-name':
124.124.124.in-addr.arpa.
631 Scope Ok - scope(scope2) property 'dns-server-addr': 
631 Scope Ok - scope(scope2) property 'dns-zone-name': 
631 Scope Ok - scope(scope2) property 'dynamic-bootp': disabled
631 Scope Ok - scope(scope2) property 'dynamic-dns': disabled
631 Scope Ok - scope(scope2) property 'failover': use-server-settings
631 Scope Ok - scope(scope2) property 'failover-backup-server': 
631 Scope Ok - scope(scope2) property 'failover-main-server': 
631 Scope Ok - scope(scope2) property 'mask': 255.255.255.0
631 Scope Ok - scope(scope2) property 'ping-clients': disabled
631 Scope Ok - scope(scope2) property 'ping-timeout': 300
631 Scope Ok - scope(scope2) property 'policy': default
631 Scope Ok - scope(scope2) property 'primary-addr': 
631 Scope Ok - scope(scope2) property 'primary-mask': 
631 Scope Ok - scope(scope2) property 'primary-scope': 
631 Scope Ok - scope(scope2) property 'renew-only': 
631 Scope Ok - scope(scope2) property 'selection-tags': 
631 Scope Ok - scope(scope2) property 'synthesize-name': disabled
631 Scope Ok - scope(scope2) property 'synthetic-name-stem': dhcp
631 Scope Ok - scope(scope2) property 'trap-free-address-high': enabled
631 Scope Ok - scope(scope2) property 'trap-free-address-high-threshold': 
631 Scope Ok - scope(scope2) property 'trap-free-address-low': 
631 Scope Ok - scope(scope2) property 'trap-free-address-low-threshold': 
631 Scope Ok - scope(scope2) property 'update-dns-first': disabled
631 Scope Ok - scope(scope2) property 'update-dns-for-bootp': 
631 Scope Ok - scope(scope2) property 'Rangelist': {2088532993 2088533012}
612 Compare policy properties - policy(system_default_policy) on main(sfo5)
to backup(sfo6)
632 Policy Ok - policy(system_default_policy) property
'allow-lease-time-override': enabled
632 Policy Ok - policy(system_default_policy) property 'permanent-leases':
disabled
632 Policy Ok - policy(system_default_policy) property 'split-lease-times':
disabled
632 Policy Ok - policy(system_default_policy) property 'bootp-reply-options': 
632 Policy Ok - policy(system_default_policy) property 'dhcp-reply-options': 
632 Policy Ok - policy(system_default_policy) property 'grace-period': 5m
632 Policy Ok - policy(system_default_policy) property 'offer-timeout': 2m
632 Policy Ok - policy(system_default_policy) property 'packet-file-name': 
632 Policy Ok - policy(system_default_policy) property 'packet-server-name': 
632 Policy Ok - policy(system_default_policy) property 'packet-siaddr': 
632 Policy Ok - policy(system_default_policy) property 'server-lease-time': 
632 Policy Ok - policy(system_default_policy) option 'all-subnets-local':
FALSE
632 Policy Ok - policy(system_default_policy) option 'arp-cache-timeout': 60
632 Policy Ok - policy(system_default_policy) option 'broadcast-address':
255.255.255.255
632 Policy Ok - policy(system_default_policy) option 'default-ip-ttl': 64
632 Policy Ok - policy(system_default_policy) option 'default-tcp-ttl': 64
632 Policy Ok - policy(system_default_policy) option 'dhcp-lease-time': 604800
632 Policy Ok - policy(system_default_policy) option
'ieee802.3-encapsulation': FALSE
632 Policy Ok - policy(system_default_policy) option 'interface-mtu': 576
632 Policy Ok - policy(system_default_policy) option 'mask-supplier': FALSE
632 Policy Ok - policy(system_default_policy) option
'max-dgram-reassembly': 576
632 Policy Ok - policy(system_default_policy) option
'non-local-source-routing': FALSE
632 Policy Ok - policy(system_default_policy) option
'path-mtu-aging-timeout': 6000
632 Policy Ok - policy(system_default_policy) option
'path-mtu-plateau-tables': 68,69
632 Policy Ok - policy(system_default_policy) option
'perform-mask-discovery': FALSE
632 Policy Ok - policy(system_default_policy) option 'router-discovery': TRUE
632 Policy Ok - policy(system_default_policy) option
'router-solicitation-address': 224.0.0.2
632 Policy Ok - policy(system_default_policy) option
'tcp-keepalive-garbage': FALSE
632 Policy Ok - policy(system_default_policy) option
'tcp-keepalive-interval': 0
632 Policy Ok - policy(system_default_policy) option
'trailer-encapsulation': FALSE
612 Compare policy properties - policy(policy1) on main(sfo5) to backup(sfo6)
632 Policy Ok - policy(policy1) property 'allow-lease-time-override': enabled
632 Policy Ok - policy(policy1) property 'permanent-leases': disabled
632 Policy Ok - policy(policy1) property 'split-lease-times': disabled
632 Policy Ok - policy(policy1) property 'bootp-reply-options': 
632 Policy Ok - policy(policy1) property 'dhcp-reply-options': 
632 Policy Ok - policy(policy1) property 'grace-period': 5m
632 Policy Ok - policy(policy1) property 'offer-timeout': 2m
632 Policy Ok - policy(policy1) property 'packet-file-name': 
632 Policy Ok - policy(policy1) property 'packet-server-name': 
632 Policy Ok - policy(policy1) property 'packet-siaddr': 
632 Policy Ok - policy(policy1) property 'server-lease-time': 
632 Policy Ok - policy(policy1) option 'www-servers': 222.222.222.222
612 Compare policy properties - policy(default) on main(sfo5) to backup(sfo6)
632 Policy Ok - policy(default) property'allow-lease-time-override':enabled
632 Policy Ok - policy(default) property 'permanent-leases': disabled
632 Policy Ok - policy(default) property 'split-lease-times': disabled
632 Policy Ok - policy(default) property 'bootp-reply-options': 
632 Policy Ok - policy(default) property 'dhcp-reply-options': 
632 Policy Ok - policy(default) property 'grace-period': 5m
632 Policy Ok - policy(default) property 'offer-timeout': 2m
632 Policy Ok - policy(default) property 'packet-file-name': 
632 Policy Ok - policy(default) property 'packet-server-name': 
632 Policy Ok - policy(default) property 'packet-siaddr': 
632 Policy Ok - policy(default) property 'server-lease-time': 
632 Policy Ok - policy(default) option 'dhcp-lease-time': 604800
100 Ok
==sfo5,opasvt(2)>>

Output File With Errors

The following display shows a sample output file containing errors. The error lines contain the word "difference." The errors in this display are highlighted in boldface text.

610 Compare global properties - main(sfo5) to backup(sfo6)
630 Global Ok - property 'failover': on
630 Global Ok - property 'failover-backup-percentage': 10
630 Global Ok - property 'failover-backup-server': sfo6
630 Global Ok - property 'failover-dynamic-bootp-backup-percentage': 
630 Global Ok - property 'failover-lease-period-factor': 1.50
620 Global difference - 'failover-main-server': main(sfo5)=sfo5
backup(sfo6)=yuck
630 Global Ok - property 'failover-maximum-client-lead-time': 60m
630 Global Ok - property 'failover-poll-interval': 15s
630 Global Ok - property 'failover-poll-timeout': 60s
630 Global Ok - property 'failover-recover': Wed Dec 31 19:00:00 1969
630 Global Ok - property 'failover-safe-period': 24h
630 Global Ok - property 'failover-use-safe-period': disabled
611 Compare scope properties - scope(scope1) on main(sfo5) to backup(sfo6)
631 Scope Ok - scope(scope1) property 'addr': 123.123.123.0
631 Scope Ok - scope(scope1) property 'bootp': disabled
631 Scope Ok - scope(scope1) property 'deactivated': 
631 Scope Ok - scope(scope1) property 'dhcp': enabled
631 Scope Ok - scope(scope1) property 'dns-rev-server-addr': 
631 Scope Ok - scope(scope1) property 'dns-reverse-zone-name':
123.123.123.in-addr.arpa.
631 Scope Ok - scope(scope1) property 'dns-server-addr': 
631 Scope Ok - scope(scope1) property 'dns-zone-name': 
631 Scope Ok - scope(scope1) property 'dynamic-bootp': disabled
631 Scope Ok - scope(scope1) property 'dynamic-dns': disabled
631 Scope Ok - scope(scope1) property 'failover': use-server-settings
631 Scope Ok - scope(scope1) property 'failover-backup-server': 
631 Scope Ok - scope(scope1) property 'failover-main-server': 
631 Scope Ok - scope(scope1) property 'mask': 255.255.255.0
631 Scope Ok - scope(scope1) property 'ping-clients': disabled
631 Scope Ok - scope(scope1) property 'ping-timeout': 300
631 Scope Ok - scope(scope1) property 'policy': policy1
631 Scope Ok - scope(scope1) property 'primary-addr': 
631 Scope Ok - scope(scope1) property 'primary-mask': 
631 Scope Ok - scope(scope1) property 'primary-scope': 
631 Scope Ok - scope(scope1) property 'renew-only': 
631 Scope Ok - scope(scope1) property 'selection-tags': 
631 Scope Ok - scope(scope1) property 'synthesize-name': disabled
631 Scope Ok - scope(scope1) property 'synthetic-name-stem': dhcp
631 Scope Ok - scope(scope1) property 'trap-free-address-high': enabled
631 Scope Ok - scope(scope1) property 'trap-free-address-high-threshold': 
631 Scope Ok - scope(scope1) property 'trap-free-address-low': 
631 Scope Ok - scope(scope1) property 'trap-free-address-low-threshold': 
631 Scope Ok - scope(scope1) property 'update-dns-first': disabled
631 Scope Ok - scope(scope1) property 'update-dns-for-bootp': 
622 Scope range difference - scope(scope1) range
'123.123.123.30-123.123.123.40' on backup(sfo6) not on main(sfo5)
611 Compare scope properties - scope(scope2) on main(sfo5) to backup(sfo6)
631 Scope Ok - scope(scope2) property 'addr': 124.124.124.0
631 Scope Ok - scope(scope2) property 'bootp': disabled
631 Scope Ok - scope(scope2) property 'deactivated': 
631 Scope Ok - scope(scope2) property 'dhcp': enabled
631 Scope Ok - scope(scope2) property 'dns-rev-server-addr': 
631 Scope Ok - scope(scope2) property 'dns-reverse-zone-name':
124.124.124.in-addr.arpa.
631 Scope Ok - scope(scope2) property 'dns-server-addr': 
631 Scope Ok - scope(scope2) property 'dns-zone-name': 
631 Scope Ok - scope(scope2) property 'dynamic-bootp': disabled
631 Scope Ok - scope(scope2) property 'dynamic-dns': disabled
631 Scope Ok - scope(scope2) property 'failover': use-server-settings
631 Scope Ok - scope(scope2) property 'failover-backup-server': 
631 Scope Ok - scope(scope2) property 'failover-main-server': 
631 Scope Ok - scope(scope2) property 'mask': 255.255.255.0
631 Scope Ok - scope(scope2) property 'ping-clients': disabled
631 Scope Ok - scope(scope2) property 'ping-timeout': 300
631 Scope Ok - scope(scope2) property 'policy': default
631 Scope Ok - scope(scope2) property 'primary-addr': 
631 Scope Ok - scope(scope2) property 'primary-mask': 
631 Scope Ok - scope(scope2) property 'primary-scope': 
631 Scope Ok - scope(scope2) property 'renew-only': 
631 Scope Ok - scope(scope2) property 'selection-tags': 
631 Scope Ok - scope(scope2) property 'synthesize-name': disabled
631 Scope Ok - scope(scope2) property 'synthetic-name-stem': dhcp
631 Scope Ok - scope(scope2) property 'trap-free-address-high': enabled
631 Scope Ok - scope(scope2) property 'trap-free-address-high-threshold': 
631 Scope Ok - scope(scope2) property 'trap-free-address-low': 
631 Scope Ok - scope(scope2) property 'trap-free-address-low-threshold': 
631 Scope Ok - scope(scope2) property 'update-dns-first': disabled
631 Scope Ok - scope(scope2) property 'update-dns-for-bootp': 
631 Scope Ok - scope(scope2) property 'Rangelist': {2088532993 2088533012}
612 Compare policy properties - policy(system_default_policy) on main(sfo5)
to backup(sfo6)
632 Policy Ok - policy(system_default_policy) property
'allow-lease-time-override': enabled
632 Policy Ok - policy(system_default_policy) property 'permanent-leases':
disabled
632 Policy Ok - policy(system_default_policy) property 'split-lease-times':
disabled
632 Policy Ok - policy(system_default_policy) property 'bootp-reply-options': 
632 Policy Ok - policy(system_default_policy) property 'dhcp-reply-options': 
632 Policy Ok - policy(system_default_policy) property 'grace-period': 5m
632 Policy Ok - policy(system_default_policy) property 'offer-timeout': 2m
632 Policy Ok - policy(system_default_policy) property 'packet-file-name': 
632 Policy Ok - policy(system_default_policy) property 'packet-server-name': 
632 Policy Ok - policy(system_default_policy) property 'packet-siaddr': 
632 Policy Ok - policy(system_default_policy) property 'server-lease-time': 
632 Policy Ok - policy(system_default_policy) option 'all-subnets-local':
FALSE
632 Policy Ok - policy(system_default_policy) option 'arp-cache-timeout': 60
632 Policy Ok - policy(system_default_policy) option 'broadcast-address':
255.255.255.255
632 Policy Ok - policy(system_default_policy) option 'default-ip-ttl': 64
632 Policy Ok - policy(system_default_policy) option 'default-tcp-ttl': 64
632 Policy Ok - policy(system_default_policy) option 'dhcp-lease-time': 604800
632 Policy Ok - policy(system_default_policy) option
'ieee802.3-encapsulation': FALSE
632 Policy Ok - policy(system_default_policy) option 'interface-mtu': 576
632 Policy Ok - policy(system_default_policy) option 'mask-supplier': FALSE
632 Policy Ok - policy(system_default_policy) option
'max-dgram-reassembly': 576
632 Policy Ok - policy(system_default_policy) option
'non-local-source-routing': FALSE
632 Policy Ok - policy(system_default_policy) option
'path-mtu-aging-timeout': 6000
632 Policy Ok - policy(system_default_policy) option
'path-mtu-plateau-tables': 68,69
632 Policy Ok - policy(system_default_policy) option
'perform-mask-discovery': FALSE
632 Policy Ok - policy(system_default_policy) option 'router-discovery': TRUE
632 Policy Ok - policy(system_default_policy) option
'router-solicitation-address': 224.0.0.2
632 Policy Ok - policy(system_default_policy) option
'tcp-keepalive-garbage': FALSE
632 Policy Ok - policy(system_default_policy) option
'tcp-keepalive-interval': 0
632 Policy Ok - policy(system_default_policy) option
'trailer-encapsulation': FALSE
612 Compare policy properties - policy(policy1) on main(sfo5) to backup(sfo6)
632 Policy Ok - policy(policy1) property 'allow-lease-time-override': enabled
632 Policy Ok - policy(policy1) property 'permanent-leases': disabled
632 Policy Ok - policy(policy1) property 'split-lease-times': disabled
632 Policy Ok - policy(policy1) property 'bootp-reply-options': 
632 Policy Ok - policy(policy1) property 'dhcp-reply-options': 
632 Policy Ok - policy(policy1) property 'grace-period': 5m
632 Policy Ok - policy(policy1) property 'offer-timeout': 2m
632 Policy Ok - policy(policy1) property 'packet-file-name': 
632 Policy Ok - policy(policy1) property 'packet-server-name': 
632 Policy Ok - policy(policy1) property 'packet-siaddr': 
632 Policy Ok - policy(policy1) property 'server-lease-time': 
632 Policy Ok - policy(policy1) option 'www-servers': 222.222.222.222
612 Compare policy properties - policy(default) on main(sfo5) to backup(sfo6)
632 Policy Ok - policy(default) property 'allow-lease-time-override': enabled
632 Policy Ok - policy(default) property 'permanent-leases': disabled
632 Policy Ok - policy(default) property 'split-lease-times': disabled
632 Policy Ok - policy(default) property 'bootp-reply-options': 
632 Policy Ok - policy(default) property 'dhcp-reply-options': 
632 Policy Ok - policy(default) property 'grace-period': 5m
632 Policy Ok - policy(default) property 'offer-timeout': 2m
632 Policy Ok - policy(default) property 'packet-file-name': 
632 Policy Ok - policy(default) property 'packet-server-name': 
632 Policy Ok - policy(default) property 'packet-siaddr': 
632 Policy Ok - policy(default) property 'server-lease-time': 
632 Policy Ok - policy(default) option 'dhcp-lease-time': 604800
600 Failover configuration differences found
==sfo5,opasvt(2)>>

Table of Contents

Configuring Failover

Sample Script

System Defaults

Sample Script

Static BOOTP

Dynamic BOOTP

Automatically Setting PARTNER-DOWN State

Manually Setting PARTNER-DOWN State

Using the CLI:

Using the GUI: