Cisco Network Registrar User's Guide, 6.2.1
4 - Local and Regional Administrators
Downloads: This chapterpdf (PDF - 663.0KB) The complete bookPDF (PDF - 8.15MB) | Feedback

Configuring Local and Regional Administrators

Table Of Contents

Configuring Local and Regional Administrators

Administrators, Groups, and Roles

How Administrators Relate to Groups and Roles

Administrator Types

Roles and Subroles

Groups

Adding Administrators

Adding Groups

Adding Roles

Managing Passwords

Listing and Deleting Administrators

Licensing

Centrally Managing Administrators

Pushing and Pulling Administrators

Pushing Administrators to Local Clusters

Pulling Administrators from the Replica Database

Pushing and Pulling Groups

Pushing Groups to Local Clusters

Pulling Groups from the Replica Database

Pushing and Pulling Roles

Pushing Roles to Local Clusters

Pulling Roles from the Replica Database

Pushing and Pulling Owners or Regions

Pushing Owners or Regions to Local Clusters

Pulling Owners or Regions from the Replica Database

Local Cluster Management Tutorial

Administrator Responsibilities and Tasks

Create the Administrators

Create the Address Infrastructure

Create the Zone Infrastructure

Create the Forward Zones

Create the Reverse Zones

Create the Initial Hosts

Create a Host Administrator Role with Constraints

Create a Group to Assign to the Host Administrator

Test the Host Address Range

Regional Cluster Management Tutorial

Administrator Responsibilities and Tasks

Create the Regional Cluster Administrator

Create the Central Configuration Administrator

Add the Address Space and Router Licenses

Create the Local Clusters

Add a Router and Modify an Interface

Add Zone Management to the Configuration Administrator

Create a Zone for the Local Cluster

Pull Zone Data and Create a Zone Distribution

Create a Subnet and Pull Address Space

Push a DHCP Policy

Create a Scope Template

Create and Synchronize the Failover Pair


Configuring Local and Regional Administrators


This chapter explains how to set up network administrators at the local and regional clusters through Cisco CNS Network Registrar's Web-based user interface (Web UI) and command line interface (CLI). The chapter also includes local and regional cluster tutorials for many of the administration features.

Administrators, Groups, and Roles

The types of functions that network administrators can perform in Network Registrar are based on the roles that they are assigned. Local and regional administrators can define these roles to provide granularity for the network administration functions. Network Registrar predefines a set of base roles that segment the administrative functions. From these base roles you can define further constrained roles that are limited to administering particular addresses, zones, and other network objects.

The mechanism to associate administrators with their roles is to place the administrators in groups that include these roles.

How Administrators Relate to Groups and Roles

There are three administrator objects in Network Registrar—administrator, group, and role:

Administrator—An account that logs in and that, through its association with one or more administrator groups, can perform certain functions based on its assigned role or roles. At the local cluster, these functions are administering the local Central Configuration Management (CCM) server and databases, hosts, zones, address space, and DHCP. At the regional cluster, these functions administer the regional CCM server and databases, central configuration, and regional address space. An administrator must be assigned to at least one group to be effective.

Adding administrators is described in the "Adding Administrators" section.

Group—A grouping of roles. You must associate one or more groups with an administrator, and a group must be assigned at least one role to be usable. The predefined groups that Network Registrar provides map each role to a unique group.

Adding groups is described in the "Adding Groups" section.

Role—Defines the network objects that an administrator can manage and the functions that an administrator can perform. A set of predefined roles are created at installation, and you can define additional constrained roles. Some of the roles include subroles that provide further functional constraints.

Adding roles is described in the "Adding Roles" section.

Administrator Types

There are two basic types of administrators: superusers and specialized administrators:

Superuser—Administrator with unrestricted access to the Web UI, CLI, and all features. This administrator type should be restricted to a few individuals. Network Registrar includes one superuser administrator by default (admin) with the password changeme. It appears by default in the list of administrators in the Web UI (see Figure 4-1). The superuser privileges of an administrator override all its other roles.


Tip Immediately change the default password after installing Network Registrar.


Specialized—Administrator created by name to fulfill specialized functions, for example, to administer a specific DNS forward or reverse zone, based on the administrator's assigned role (and subrole, if applicable). Specialized administrators, like the superuser, require a password, but must also be assigned at least one administrator group that defines the relevant roles. The entry fields in the Web UI appear in Figure 4-1. The CLI provides the admin command.

For an example of creating a local zone or host administrator, see the "Create the Administrators" section.

Roles and Subroles

You can limit an administrator role by applying constraints. For example, you can use the host-admin base role to create a host administrator, named 192.168.50.0-host-admin, who is constrained to the 192.168.50.0 subnet. The administrator assigned a group that includes this role then logs in with this constraint in effect. Adding roles and subroles is described in the "Adding Roles" section.

You can further limit the constraints on roles to read-only access. An administrator can be allowed to read any of the data for that role, but not modify it. However, if read-write mode applies from any associated role, it supersedes the read-only constraints from all the other roles. An example of adding constraints is described in the "Create a Host Administrator Role with Constraints" section.

The interplay between zone and host role assignments is such that you can combine an unconstrained dns-admin role with any host-admin role in a group. For example, combining the dns-admin-readonly role and a host-admin role in a group (and naming the group host-rw-dns-ro) provides full host access and read-only access to zones and RRs. However, if you assign a constrained dns-admin role along with a host-admin role to a group and then to an administrator, the constrained dns-admin role takes precedence, and the administrator's privileges at login will preclude any host administration.

Certain roles provide subroles with which you can further limit the role functionality. For example, the local ccm-admin or regional-admin, with just the owner-region subrole applied, can manage only owners and regions. By default, all the possible subroles apply when you create a constrained role.

The predefined roles are described in Table 4-1 (local), and Table 4-2 (regional).

Table 4-1 Local Cluster Administrator Predefined and Base Roles 

Local Role
Subroles, License Requirements, and Active Functionality

addrblock-admin

Core functionality (local-cluster license): Manage address block, subnets, and reverse DNS zones (also requires dns-admin); and notify of scope activity.

ric-management (router license): Push to, and reclaim subnets from, DHCP failover pairs and routers.

ccm-admin

Core functionality (local-cluster license): Manage licenses, access control lists (ACLs), and encryption keys.

authentication: Manage administrators.

authorization: Manage roles and groups.

owner-region: Manage owners and regions.

database: View database change entries and trim the CCM change sets.

cfg-admin

Core functionality (local-cluster license): Manage clusters.

ccm-management: Manage the CCM server configuration.

dhcp-management: Manage the DHCP server configuration.

dns-management: Manage the DNS server configuration.

ric-management (router license): Manage routers.

snmp-management: Manage the SNMP server configuration.

tftp-management: Manage the TFTP server configuration.

dhcp-admin

Core functionality (local-cluster license): Manage DHCP scopes and templates, policies, clients, client-classes, options, leases, and reservations.

server-management: Manage the DHCP server configuration, failover pairs, LDAP servers, extensions, and statistics.

ipv6-management (ipv6 license): Manage IPv6 prefixes, links, options, leases, and reservations.

dns-admin

Core functionality (local-cluster license): Manage DNS zones and templates, resource records, secondary servers, and hosts.

security-management: Manage DNS update policies, ACLs, and encryption keys.

server-management: Manage DNS server configurations and zone distributions, synchronize zones and HA server pairs, and push update maps.

host-admin

Core functionality (local-cluster license): Manage DNS hosts. (Note that if an administrator is also assigned a constrained dns-admin role that overrides the host-admin definition, the administrator is not assigned the host-admin role.)


Table 4-2 Regional Cluster Administrator Predefined and Base Roles 

Regional Role
Subroles, License Requirements, and Active Functionality

central-cfg-admin

Core functionality (central-cluster license): Manage clusters and view replica data.

dhcp-management: Manage DHCP scope templates, policies, client-classes, failover pairs, virtual private networks (VPNs), and options; modify subnets; and replicate data.

ric-management (router license): Manage routers and router interfaces, and pull replica router data.

central-dns-admin

Core functionality (central-cluster license): Manage DNS zones and templates, hosts, resource records, and secondary servers; and create subzones and reverse zones.

security-management: Manage DNS update policies, ACLs, and encryption keys.

server-management: Synchronize DNS zones and HA server pairs, manage zone distributions, pull replica zone data, and push update maps.

central-host-admin

Core functionality (central-cluster license): Manage DNS hosts. (Note that if an administrator is also assigned a constrained central-dns-admin role that overrides the central-host-admin definition, the administrator is not assigned the central-host-admin role.)

regional-admin

Core functionality (central-cluster license): Manage licenses and encryption keys.

authentication: Manage administrators.

authorization: Manage roles and groups.

owner-region: Manage owners and regions.

database: View database change entries and trim the CCM change sets.

regional-addr-admin

Core functionality (central-cluster and addrspace licenses): Manage address blocks, subnets, and address ranges; generate allocation reports; and pull replica address space data.

dhcp-management (addrspace license): Push and reclaim subnets; and add subnets to, and remove subnets from, DHCP failover pairs.

lease-history (addrspace license): Query, poll, and trim lease history data.

subnet-utilization (addrspace license): Query, poll, trim, and compact subnet utilization data.


Groups

Administrator groups are the mechanism used to assign roles to administrators. Hence, a group must consist of one or more administrator roles to be usable. When you first install Network Registrar, a predefined group is created to correspond to each predefined role.

When a group is assigned multiple roles, constraints are defined as a sum of all the roles. For example, if one of the roles is assigned unconstrained read-write privileges, the group is assigned unconstrained read-write privileges, even though other roles might be assigned read-only privileges. Therefore, to limit a user's read-write privileges while allowing read-only access to all data, create a group that includes the unconstrained read-only role along with a constrained read-write role. (See the "Roles and Subroles" section for the implementation of host-admin and dns-admin roles combined in a group.)


Note Upgrading from Network Registrar 6.0 or 6.1 does not create groups for each predefined role. However, groups are created for administrators that had direct role assignments in the earlier releases. These group names are the original role names appended with -group (and a number if there already is a group by that name).


Adding Administrators

The Network Registrar Web UIs have only one predefined administrator, the admin account. This superuser can exercise all the functions of the Web UI and usually adds the other key administrators. Adding an administrator requires:

Adding an administrator name.

Adding a password.

Determining if the administrator should have full or limited access to the CLI.

Determining if the administrator should have superuser privileges—Usually assigned on an extremely limited basis.

Determining the group or groups to which the administrator should belong. These groups should have the appropriate role (and possibly subrole) assignments, thereby setting the proper constraints.

Some of the specifics about creating administrators are described in the "Local Cluster Management Tutorial" section and "Regional Cluster Management Tutorial" section.

In the local and regional Web UIs, click Administration, then Administrators. This opens the List/Add Administrators page (see Figure 4-3).

In the CLI, use admin name create (see the admin command in the Network Registrar CLI Reference for syntax and attribute descriptions). You must have at least ccm-admin or regional-admin privileges to use this command.


Tip If you accidentally delete all the roles by which you can log in to Network Registrar (those having superuser, ccm-admin, or regional-admin privileges), you can recover by creating a username/password pair in the install-path/conf/priv/local.superusers file. You must create this file, have write access to it, and include a line in it with the format username password. After creating the file, stop and restart the Network Registrar server agent. Use this username and password for the next login session. Note, however, that using the local.superusers file causes reduced security. Therefore, use this file only in emergencies such as when temporarily losing all login access. Once logged in, create a superuser account in the usual way, then delete the local.superusers file or its contents.


Adding Groups

In the local and regional Web UIs, click Administration, then Groups. This opens the List/Add Administrator Groups page (see Figure 4-13).

In the CLI, use group name create (see the group command in the Network Registrar CLI Reference for syntax and attribute descriptions). You must have at least ccm-admin or regional-admin privileges to use this command.

Some of the specifics about creating groups are described in the "Local Cluster Management Tutorial" section and "Regional Cluster Management Tutorial" section.

Adding Roles

In the local and regional Web UIs, click Administration, then Roles. This opens the List/Add Administrator Roles page (see Figure 4-11).

In the CLI, use role name create base-role (see the role command in the Network Registrar CLI Reference for syntax and attribute descriptions). The base roles have default groups associated with them. To add others, set the groups attribute (a comma-separated string value). You must have at least ccm-admin or regional-admin privileges to use this command.

Some of the specifics about creating roles are described in the "Local Cluster Management Tutorial" section and "Regional Cluster Management Tutorial" section.

Managing Passwords

Passwords are key to administrator access to the Web UI and CLI. In the Web UI, you enter the password on the Login page. In the CLI, you enter the password when you first invoke the nrcmd program. The local or regional CCM administrator or superuser can change any administrator's password. You can prevent exposing a password on entry:

In the Web UI, logging in or adding a password never exposes it on the page, except as asterisks.

In the CLI, you can prevent exposing the password by creating an administrator, omitting the password, then using admin name enterPassword, where the prompt displays the password as asterisks. You can do this instead of the usual admin name set password command that exposes the password as plain text.

Any administrator can change their own password on a given cluster. If you want the password change propagated from the regional to local clusters, you must change the password at the regional cluster, then use the regional administrator push function to push the new setting to the other clusters (see the "Pushing and Pulling Administrators" section). You must have regional CCM administrator or superuser privileges; otherwise, you must have the regional administrator do it for you.

Listing and Deleting Administrators

If you have full administrator privileges, you can list the administrators and delete specific ones, if necessary. (If you lack full administrator privileges, an error message appears.)

In the Web UI, the superuser, and local and regional CCM administrators can list and delete administrators at any time.

In the CLI, list the administrators by using admin list or admin listnames, and delete an administrator by using admin name delete.

Licensing

Regional and local cluster operations require at least one license. The regional cluster requires the central-cluster license, and the local cluster requires the local-cluster license. Certain functions for address space at the regional cluster, and router and IPv6 addressing functions at the regional and local clusters, require additional licenses. (See Table 4-1 and Table 4-2 for the licenses required for each administrator role.) The licenses are:

central-cluster—Core regional cluster management.

local-cluster—Core local cluster management.

addrspace—Regional management of subnets and address blocks. (For an example of adding an address space license, see the "Add the Address Space and Router Licenses" section.)

ipv6—Local management of the IPv6 address space.

router—Regional and local management of the Router Interface Configuration (RIC) server. (For an example of adding a router license, see the "Add the Address Space and Router Licenses" section.)

node-count—Regional and local management of a certain number of address nodes.

Centrally Managing Administrators

As a regional or local CCM administrator, you can:

Create and modify local and regional cluster administrators, groups, and roles.

Push administrators, groups, roles, owners, and regions to local clusters.

Pull local cluster administrators, groups, roles, owners, and regions to the central cluster.

Each of these functions involves having at least one regional CCM administrator subrole defined. Table 4-3 describes the subroles required for these operations.

Table 4-3 Subroles Required for Central Administrator Management 

Central Administrator Management Action
Required Regional Subroles

Create, modify, push, pull, or delete administrators

authentication

Create, modify, push, pull, or delete groups or roles

authorization

Create, modify, pull, push, or delete owners or regions

owner-region

Create, modify, push, pull, or delete groups or roles with associated owners or regions

authorization
owner-region


Pushing and Pulling Administrators

You can push administrators to, and pull administrators from, local clusters on the List/Add Administrators page in the regional cluster Web UI (see Figure 4-1).

Figure 4-1 List/Add Administrators Page (Local)

You can create administrators with both local and regional roles at the regional cluster. However, you can push or pull only associated local roles, because local clusters do not recognize regional roles.

Pushing Administrators to Local Clusters

Pushing administrators to local clusters involves choosing one or more clusters and a push mode:


Step 1 Click Administration in the regional cluster Web UI, then Administrators.

Step 2 On the List/Add Administrators Page, click Push All Administrators to push all the administrators listed on the page, or Push Admin next to an individual administrator. This opens the Push Administrator Data to Local Clusters page.

Step 3 Choose a push mode by clicking one of the Data Synchronization Mode radio buttons. If you are pushing all the administrators, you can choose Ensure, Replace, or Exact. If you are pushing a single administrator, you can choose Ensure or Replace. In both cases, Ensure is the default mode. You would choose Replace only if you want to replace the existing administrator data at the local cluster. You would choose Exact only if you want to create an exact copy of the administrator database at the local cluster, thereby deleting all administrators that are not defined at the regional cluster.

Step 4 Choose one or more local clusters in the Available field of the Destination Clusters and move it or them to the Selected field.

Step 5 Click Push Data to Clusters.

Step 6 On the View Push Administrator Data Report page, view the push details, then click OK to return to the List/Add Administrators page.

Step 7 To confirm that administrators are pushed successfully, click Clusters, then Cluster Tree to open the View Tree of Server Clusters page. Click the Go Local icon () next to the cluster name to open the Web UI for the local cluster, then verify that the administrator or administrators are added to the cluster.


Pulling Administrators from the Replica Database

Pulling administrators from the local clusters is mainly useful only in creating an initial list of administrators that can then be pushed to other local clusters. The local administrators are not effective at the regional cluster itself, because these administrators do not have regional roles assigned to them.

When you pull an administrator, you are actually pulling it from the regional cluster's replica database. Creating the local cluster initially replicates the data, and periodic polling automatically updates the replication. However, to ensure that the replica data is absolutely current with the local cluster, you can force an update before pulling the data. Here is the procedure to follow:


Step 1 Click Administration in the regional cluster Web UI, then Administrators.

Step 2 On the List/Add Administrators Page, click Pull Replica Administrators. This opens the Select Replica Administrator Data to Pull page.

Step 3 Click the Replicate icon () in the Update Replica Data column for the cluster. (For the automatic replication interval, see the "Replicating Local Cluster Data" section.)

Step 4 Choose a replication mode using one of the Mode radio buttons. In most cases, you would leave the default Replace mode enabled, unless you want to preserve any existing administrator properties already defined at the regional cluster by choosing Ensure, or create an exact copy of the administrator database at the local cluster by choosing Exact (not recommended).

Step 5 Click Pull All Administrators next to the cluster, or expand the cluster name and click Pull Administrator to pull an individual administrator in the cluster.

Step 6 On the Report Pull Replica Administrators page, view the pull details, then click Run.

Step 7 On the Run Pull Replica Administrators page, view the change set data, then click OK. You return to the List/Add Administrators page with the pulled administrators added to the list.



Note If you do not have a regional cluster and would like to copy administrators, roles, or groups from one local cluster to another, you can export them and then reimport them at the target cluster by using the cnr-exim tool (see the "Using the cnr_exim Data Import and Export Tool" section). However, the tool does not preserve the administrator passwords, and you must manually reset them at the target cluster. This method maintains password security. The export command is:

cnr_exim -c admin -x -e outputfile.txt


Pushing and Pulling Groups

Pushing and pulling groups is vital in associating administrators with a consistent set of roles at the local clusters. You can push groups to, and pull groups from, local clusters on the List/Add Administrator Groups page in the regional cluster Web UI (see Figure 4-13).

Pushing Groups to Local Clusters

Pushing groups to local clusters involves choosing one or more clusters and a push mode:


Step 1 Click Administration in the regional cluster Web UI, then Groups.

Step 2 On the List/Add Administrator Groups page, click Push All Groups to push all the groups listed on the page, or Push Group next to an individual group. This opens the Push Group Data to Local Clusters page.

Step 3 Choose a push mode using one of the Data Synchronization Mode radio buttons. If you are pushing all the groups, you can choose Ensure, Replace, or Exact. If you are pushing a single group, you can choose Ensure or Replace. In both cases, Ensure is the default mode. You would choose Replace only if you want to replace the existing group data at the local cluster. You would choose Exact only if you want to create an exact copy of the group data at the local cluster, thereby deleting all groups that are not defined at the regional cluster.

Step 4 By default, the associated roles and owners are pushed along with the group. Roles are pushed in Replace mode and owners in Ensure mode. To disable pushing the associated roles or owners, remove the respective check mark.

Step 5 Choose one or more local clusters in the Available field of the Destination Clusters and move it or them to the Selected field.

Step 6 Click Push Data to Clusters.

Step 7 On the View Push Group Data Report page, view the push details, then click OK to return to the List/Add Administrator Groups page.

Step 8 To confirm that groups are pushed successfully, click Clusters, then Cluster Tree to open the View Tree of Server Clusters page. Click the Go Local icon () next to the cluster name to open the Web UI for the local cluster, then verify that the group or groups are added to the cluster.


Pulling Groups from the Replica Database

Pulling administrator groups from the local clusters is mainly useful only in creating an initial list of groups that can then be pushed to other local clusters. The local groups are not useful at the regional cluster itself, because these groups do not have regional roles assigned to them.

When you pull a group, you are actually pulling it from the regional cluster's replica database. Creating the local cluster initially replicates the data, and periodic polling automatically updates the replication. However, to ensure that the replica data is absolutely current with the local cluster, you can force an update before pulling the data. Here is the procedure to follow:


Step 1 Click Administration in the regional cluster Web UI, then Groups.

Step 2 On the List/Add Administrator Groups page, click Pull Replica Groups. This opens the Select Replica Group Data to Pull page.

Step 3 Click the Replica icon () in the Update Replica Data column for the cluster. (For the automatic replication interval, see the "Replicating Local Cluster Data" section.)

Step 4 Choose a replication mode using one of the Mode radio buttons. In most cases, you would leave the default Replace mode enabled, unless you want to preserve any existing group properties at the local cluster by choosing Ensure, or create an exact copy of the group data at the local cluster by choosing Exact (not recommended).

Step 5 Click Pull All Groups next to the cluster, or expand the cluster name and click Pull Group to pull an individual group in the cluster.

Step 6 On the Report Pull Replica Groups page, view the pull details, then click Run.

Step 7 On the Run Pull Replica Groups page, view the change set data, then click OK. You return to the List/Add Administrator Groups page with the pulled groups added to the list.


Pushing and Pulling Roles

You can push roles to, and pull roles from, local clusters on the List/Add Administrator Roles page in the regional cluster Web UI (see Figure 4-2). You can also push associated groups and owners, and pull associated owners, depending on your subrole permissions (see Table 4-3).

Figure 4-2 List/Add Administrator Roles Page (Regional)

Pushing Roles to Local Clusters

Pushing administrator roles to local clusters involves choosing one or more clusters and a push mode:


Step 1 Click Administration in the regional cluster Web UI, then Roles.

Step 2 On the List/Add Administrator Roles page, click Push All Roles to push all the roles listed on the page, or Push Role next to an individual role. This opens the Push Role Data to Local Clusters page.

Step 3 Choose a push mode using one of the Data Synchronization Mode radio buttons. If you are pushing all the roles, you can choose Ensure, Replace, or Exact. If you are pushing a single role, you can choose Ensure or Replace. In both cases, Ensure is the default mode. You would choose Replace only if you want to replace the existing role data at the local cluster. You would choose Exact only if you want to create an exact copy of the role data at the local cluster, thereby deleting all roles that are not defined at the regional cluster.

Step 4 By default, the associated groups and owners are pushed along with the role. Groups are pushed in Replace mode and owners in Ensure mode. To disable pushing the associated roles or owners, remove the respective check mark:

If you disable pushing associated groups and the group does not exist at the local cluster, a group based on the name of the role is created at the local cluster.

If you disable pushing associated owners and the owner does not exist at the local cluster, the role will not be configured with its intended constraints. You must separately push the group to the local cluster, or ensure that the regional administrator assigned the owner-region subrole has pushed the group before pushing the role.

Step 5 Choose one or more local clusters in the Available field of the Destination Clusters and move it or them to the Selected field.

Step 6 Click Push Data to Clusters.

Step 7 On the View Push Role Data Report page, view the push details, then click OK to return to the List/Add Administrator Roles page.

Step 8 To confirm that roles are pushed successfully, click Clusters, then Cluster Tree to open the View Tree of Server Clusters page. Click the Go Local icon () next to the cluster name to open the Web UI for the local cluster, then verify that the role or roles are added to the cluster.


Pulling Roles from the Replica Database

Pulling administrator roles from the local clusters is mainly useful only in creating an initial list of roles that can then be pushed to other local clusters. The local roles are not useful at the regional cluster itself.

When you pull a role, you are actually pulling it from the regional cluster's replica database. Creating the local cluster initially replicates the data, and periodic polling automatically updates the replication. However, to ensure that the replica data is absolutely current with the local cluster, you can force an update before pulling the data. Here is the procedure to follow:


Step 1 Click Administration in the regional cluster Web UI, then Roles.

Step 2 On the List/Add Administrator Roles page, click Pull Replica Roles. This opens the Select Replica Role Data to Pull page.

Step 3 Click the Replicate icon () in the Update Replica Data column for the cluster. (For the automatic replication interval, see the "Replicating Local Cluster Data" section.)

Step 4 Choose a replication mode using one of the Mode radio buttons. In most cases, you would leave the default Replace mode enabled, unless you want to preserve any existing role properties at the local cluster by choosing Ensure, or create an exact copy of the role data at the local cluster by choosing Exact (not recommended).

Step 5 If you have the owner-region subrole permission, you can decide if you want to pull all the associated owners with the role, which is always in Ensure mode. This choice is enabled by default.

Step 6 Click Pull All Roles next to the cluster, or expand the cluster name and click Pull Role to pull an individual role in the cluster.

Step 7 On the Report Pull Replica Roles page, view the pull details, then click Run.

Step 8 On the Run Pull Replica Roles page, view the change set data, then click OK. You return to the List/Add Administrator Roles page with the pulled roles added to the list.


Pushing and Pulling Owners or Regions

You can push owners or regions to, and pull them from, local clusters on the List/Add Owners page or List/Add Regions page, respectively, in the regional cluster Web UI.

Pushing Owners or Regions to Local Clusters

Pushing owners or regions to local clusters involves choosing one or more clusters and a push mode:


Step 1 Click Administration in the regional cluster Web UI, then Owners or Regions.

Step 2 On the List/Add Owners or List/Add Regions page, click Push All Owners or Push All Regions to push all the owners or regions listed on the page, or Push Owner or Push Region next to an individual owner or region. This opens the Push Owner Data to Local Clusters or Push Owner Data to Local Clusters page.

Step 3 Choose a push mode using one of the Data Synchronization Mode radio buttons. If you are pushing all the owners or regions, you can choose Ensure, Replace, or Exact. If you are pushing a single owner or region, you can choose Ensure or Replace. In both cases, Ensure is the default mode. You would choose Replace only if you want to replace the existing owner or region data at the local cluster. You would choose Exact only if you want to create an exact copy of the owner or region data at the local cluster, thereby deleting all owners or regions that are not defined at the regional cluster.

Step 4 Choose one or more local clusters in the Available field of the Destination Clusters and move it or them to the Selected field.

Step 5 Click Push Data to Clusters.

Step 6 On the View Push Owner Data Report or View Push Region Data Report page, view the push details, then click OK to return to the List/Add Owners or List/Add Regions page.

Step 7 To confirm that owners or regions are pushed successfully, click Clusters, then Cluster Tree to open the View Tree of Server Clusters page. Click the Go Local icon () next to the cluster name to open the Web UI for the local cluster, then verify that the owners or regions are added to the cluster.


Pulling Owners or Regions from the Replica Database

When you pull an owner or region, you are actually pulling it from the regional cluster's replica database. Creating the local cluster initially replicates the data, and periodic polling automatically updates the replication. However, to ensure that the replica data is absolutely current with the local cluster, you can force an update before pulling the data. Here is the procedure to follow:


Step 1 Click Administration in the regional cluster Web UI, then Owners or Regions.

Step 2 On the List/Add Owners or List/Add Regions page, click Pull Replica Owners or Pull Replica Regions. This opens the Select Replica Owner Data to Pull or Select Replica Region Data to Pull page.

Step 3 Click the Replicate icon () in the Update Replica Data column for the cluster. (For the automatic replication interval, see the "Replicating Local Cluster Data" section.)

Step 4 Choose a replication mode using one of the Mode radio buttons. In most cases, you would leave the default Replace mode enabled, unless you want to preserve any existing owner properties at the local cluster by choosing Ensure, or create an exact copy of the owner data at the local cluster by choosing Exact (not recommended).

Step 5 Click Pull All Owners or Pull All Regions next to the cluster, or expand the cluster name and click Pull Owner or Pull Region to pull an individual owner or region in the cluster.

Step 6 On the Report Pull Replica Owners or Report Pull Replica Regions page, click Run.

Step 7 On the Run Pull Replica Owners or Run Pull Replica Region page, view the change set data, then click OK. You return to the List/Add Owners or List/Add Regions page with the pulled owners or regions added to the list.


Local Cluster Management Tutorial

This tutorial describes a basic scenario on a local cluster of the Example Company. Administrators at the cluster are responsible for users, zone data, DHCP data, address space data, and the servers in general. The task is to set up two zones (example.com and boston.example.com), hosts in the zones, and a subnet. The local cluster must also create a special administrator account so that the regional cluster in San Jose can perform the central configuration and replicate the local cluster administrators and address space at another cluster, as described in the "Regional Cluster Management Tutorial" section.

Administrator Responsibilities and Tasks

The local cluster administrators have the following responsibilities and tasks:

example-cluster-admin (created by the superuser):

At the Boston cluster, creates the other local administrators (example-zone-admin and example-host-admin).

Creates the basic network infrastructure for the local clusters.

Constrains the example-host-role to an address range in the boston.example.com zone.

Creates the example-host-group (defined with the example-host-role) that the example-zone-admin will assign to the example-host-admin.

example-zone-admin:

Creates the example.com and boston.example.com zones, and maintains the latter zone.

Assigns the example-host-group to the example-host-admin.

example-host-admin—Maintains local host lists and IP address assignments.

Create the Administrators

For this example, the superuser in Boston creates the local cluster, zone, host, address, and DHCP administrators, as described in the "Administrator Responsibilities and Tasks" section.


Step 1 At the Boston local cluster, log in as superuser (usually admin).

Step 2 Click Administration, then Administrators.

Step 3 Add the local cluster administrator (with superuser access)—On the List/Add Administrators page:

a. Enter example-cluster-admin in the Name field. Tab to the next field.

b. Enter exampleadmin in the Password field.

c. Click the Superuser check box to add a check mark.

d. Do not choose a group from the Groups list (see Figure 4-3).

Figure 4-3 Adding a Local Cluster Administrator (Local)

e. Click Add Administrator.

Step 4 Add the local zone administrator:

a. Enter example-zone-admin in the Name field, then examplezone in the Password field.

b. Multiselect ccm-admin-group, dns-admin-group, and host-admin-group in the Groups drop-down list. The dns-admin-group is already predefined with the dns-admin role to administer DNS zones and servers. The ccm-admin-group guarantees that the example-zone-admin can set up the example-host-admin with a constrained role later on. The host-admin-group is mainly to test host creation in the zone.

c. Click Add Administrator.

Step 5 Add the local host administrator:

a. Enter example-host-admin in the Name field, then examplehost in the Password field.

b. Do not choose a group at this point. (The example-zone-admin will later assign example-host-admin to a group with a constrained role.)

c. Click Add Administrator. The page should now appear as in Figure 4-4.

Figure 4-4 Listing Local Administrators (Local)



Note For a description on how to apply constraints to the administrator, see the "Create a Host Administrator Role with Constraints" section.


Create the Address Infrastructure

A prerequisite to managing the zones and hosts at the clusters is to create the underlying network infrastructure. The network configuration often already exists and was imported. However, this tutorial assumes that you are starting with a clean slate.

The local example-cluster-admin next creates the allowable address ranges for the hosts in the boston.example.com zone that will be assigned static IP addresses. These addresses are in the 192.168.50.0/24 subnet with a range of hosts from 101 through 200.


Step 1 At the local cluster, log out as superuser, then log in as example-cluster-admin with password exampleadmin. Because the administrator is a superuser, all features are available.

Step 2 Click Address Space, then Subnets.

Step 3 On the List/Add Subnets page, enter the boston.example.com subnet address:

a. In the Address/Mask field, enter 192.168.50.0.

b. Choose 24 in the mask drop-down list—This subnet will be a normal Class C network.

c. Leave the Primary Subnet field blank—The primary subnet is the same as the subnet address.

d. Leave the Owner, Region, and Address Type fields as is. Add descriptive text if desired.

e. Click Add Subnet (see Figure 4-5).

Figure 4-5 Adding a Subnet to the Local Cluster (Local)

Step 4 Click the 192.168.50.0/24 link to open the Edit Subnet page.

Step 5 In the IP Ranges fields, enter the agreed-upon static address range:

a. Enter 101 in the Start field. Tab to the next field.

b. Enter 200 in the End field.

c. Click Add IP Range. The address range appears under the fields.

Step 6 Click Modify Subnet (see Figure 4-6).

Figure 4-6 Adding an Address Range to a Subnet (Local)

Step 7 Click Address Space to open the View Unified Address Space page. The 192.168.50.0/24 subnet should appear in the list. If not, click the Refresh icon ().


Create the Zone Infrastructure

For this scenario, example-cluster-admin must create the Example Company zones locally, including the example.com zone and its subzones. The example-cluster-admin also adds some initial host records to the boston.example.com zone.

Create the Forward Zones

First, create the example.com and boston.example.com forward zones:


Step 1 At the local cluster, log in as example-zone-admin with password examplezone. Note that only the Administration, Servers, and DNS features appear for this administrator.

Step 2 On the Main Menu page, click the DNS link to open the List/Add Zones page.

Step 3 Create the example.com zone:

a. Enter example.com in the Name field. Leave Owner, Region, and Template as is (see Figure 4-7).

Figure 4-7 Creating a Zone (Local)

b. Click Add Zone.

Step 4 On the Add Zone page, enter the minimum data required to create the zone:

a. Serial Number—Enter 1. (Tab from field to field.)

b. Nameserver—Enter ns1.

c. Contact E-Mail—Enter hostmaster.

d. In the bottom field of Nameservers—Enter ns1 (see Figure 4-8).

Figure 4-8 Adding Zone Data (Local)

e. Click Add Nameserver. The ns1 nameserver appears between the two fields.

Step 5 Click Add Zone to add the zone and return to the List/Add Zones page.

Step 6 Create the boston.example.com zone in the same way, using the same values as in the previous steps:

a. Because you want to create this zone as a subzone to example.com, click Create as Subzone on the Create Subzone in Parent Zone page.

b. Because nameservers are different in each zone, you must create a glue Address (A) record to tie the zones together. Enter 192.168.50.1 in the A record field, then click Specify Glue Records. On the next page, click Report, Run, then Return.

c. The List/Add Zones page should now list example.com and boston.example.com (see Figure 4-9).

Figure 4-9 Viewing Created Zones (Local)

Step 7 Click Show Forward Zone Tree to show the hierarchy of the zones.


Create the Reverse Zones

Next, create the reverse zones for example.com and boston.example.com. This way you can add reverse address pointer (PTR) records for each added host. The reverse zone for example.com is based on the 192.168.50.0 subnet; the reverse zone for boston.example.com is based on the 192.168.60.0 subnet.


Step 1 At the local cluster, you should be logged in as example-zone-admin, as in the previous section.

Step 2 Click Reverse Zones.

Step 3 On the List/Add Reverse Zones page, enter 50.168.192.in-addr.arpa in the Name field. (There is already a reverse zone for the loopback address, 127.in-addr.arpa.)

Step 4 Click Add Zone to open the Add Zone page.

Step 5 Enter the minimum data to create the reverse zone, using the forward zone values:

a. Serial Number—Enter 1.

b. Nameserver—Enter ns1.example.com. (be sure to include the trailing dot).

c. Contact E-Mail—Enter hostmaster.example.com. (be sure to include the trailing dot).

d. In the bottom field of Nameservers—Enter ns1.boston.example.com. (be sure to include the trailing dot to make the entry fully qualified), then click Add Nameserver.

Step 6 Click Add Zone to add the zone and return to the List/Add Reverse Zones page.

Step 7 Do the same for the boston.example.com zone, using 60.168.192.in-addr.arpa as the zone name and using the Boston zone's nameserver, contact e-mail, and nameservers values.


Create the Initial Hosts

As a confirmation that hosts can be created at the Boston cluster, the example-zone-admin tries to create two hosts in the example.com zone.


Step 1 At the local cluster, as example-zone-admin, click Host to open the List Zones page. You should see boston.example.com and example.com.

Step 2 Click example.com. in the list of zones.

Step 3 On the List/Add Hosts for Zone page, add the first static host with address 192.168.50.101:

a. Enter userhost101 in the Name field.

b. Enter the complete address 192.168.50.101 in the IP Address field. Leave the Alias(es) field blank.

c. Leave the check mark in the Create PTR Records? box.

d. Click Add Host.

Step 4 Add the second host, userhost102, with address 192.168.50.102, in the same way. The two hosts should now appear along with the nameserver host on the List/Add Hosts for Zone page (see Figure 4-10).

Figure 4-10 Adding Hosts to a Zone (Local)


Create a Host Administrator Role with Constraints

Boston's example-cluster-admin next creates the example-host-role with address constraints in the boston.example.com zone.


Step 1 At the local cluster, log out as example-zone-admin, then log in as example-cluster-admin (with password clusteradmin).

Step 2 Click Administration, then Roles to open the List/Add Administrator Roles page.

Step 3 Add the role:

a. Enter example-host-role in the Name field.

b. In the Base Role drop-down list, choose host-admin (see Figure 4-11).

Figure 4-11 Creating an Administrator Role (Local)

c. Click Add Role.

Step 4 Add the constraint:

a. On the Add Host Administrator Role page, click Add Constraint.

b. On the Add Role Constraint for Role page, scroll down to Host Restrictions.

c. For the all-forward-zones attribute, click the false radio button.

d. For the zones attribute, enter boston.example.com.

e. For the ipranges attribute, enter the range 192.168.50.101-192.168.50.200 (see Figure 4-12).

Figure 4-12 Setting Constraints for a Role (Local)

f. The zone-regexpr and host-regexpr attribute fields are for entering regular expressions to match zones and hosts, respectively, in regex syntax. Wildcard matching in regex uses the dot (.) character for "match any character" (so that you must escape each literal dot, as in zones, using a backslash, \). Other wildcards qualify the preceding character: ? ("once or not at all") , * ("zero or more times"), and + ("one or more times"). For instance, a zone-regexpr value of example.*\.com\. matches any zone that begins with "example" and has ".com." at the end. (See the online help for this page for details.)

g. Click Add Constraint. The constraint should have an index number of 1 at the bottom of the Add Host Administrator Role page.

Step 5 Click Add Role. The example-host-role should now appear in the list of roles on the List/Add Administrator Roles page.


Create a Group to Assign to the Host Administrator

Boston's example-cluster-admin next creates an example-host-group that includes the example-host-role so that the example-zone-admin can assign this group to the example-host-admin.


Step 1 Click Groups to open the List/Add Administrator Groups page.

Step 2 Create the example-host-group, assigning the example-host-role to it:

a. Enter example-host-group in the Name field.

b. Add a description such as Group for the example-host-role.

c. In the Roles drop-down list, choose example-host-role (Figure 4-13).

Figure 4-13 Creating a Group (Local)

d. Click Add Group.

e. Change the page size at the bottom of the page to 20, then click Change Page Size, so that the newly created group appears in the list.

Step 3 Log out as example-cluster-admin, then log in as example-zone-admin (with password examplezone).

Step 4 As example-zone-admin, assign the example-host-group to the example-host-admin:

a. Click Administration, then Administrators.

b. On the List/Add Administrators page, click example-host-admin to edit the administrator.

c. Choose example-host-group in the Available list, then click << to move it to the Selected list (see Figure 4-14).

Figure 4-14 Assigning a Group to an Administrator (Local)

d. Click Modify Administrator. The example-host-admin should now show example-host-group in the Groups column on the List/Add Administrators page.


Test the Host Address Range

The example-host-admin next tests an out-of-range address and then adds an acceptable one.


Step 1 At the local cluster, log out as example-zone-admin, then log in as example-host-admin (with password examplehost). Note that only the Hosts feature appears.

Step 2 On the Main Menu page, click the Hosts link.

Step 3 On the List/Add Hosts for Zone page, try to enter an out-of-range address:

a. Enter userhost3 in the Name field.

b. Deliberately enter an out-of-range address (192.168.50.3) in the IP Address field.

c. Click Add Host. You should get an error message and the fields are cleared.

Step 4 Enter a valid address:

a. Enter userhost103.

b. Enter 192.168.50.103 in the IP Address field.

c. Click Add Host. The host should now appear with that address in the list.


Regional Cluster Management Tutorial

This tutorial is an extension of the scenario described in the "Local Cluster Management Tutorial" section. In the regional cluster tutorial, San Jose has two administrators—a regional cluster administrator and a central configuration administrator. Their goal is to coordinate activities with the local clusters in Boston and Chicago so as to create DNS zone distributions, router configurations, and DHCP failover configurations using the servers at these clusters. The configuration consists of:

One regional cluster machine in San Jose.

Two local cluster machines, one in Boston and one in Chicago.

One Cisco uBR7200 router in Chicago.

Administrator Responsibilities and Tasks

The regional administrators have the following responsibilities and tasks:

example-regional-admin (created by the superuser at the San Jose regional cluster):

Creates the example-cfg-admin.

Adds the address space and router licenses.

example-cfg-admin:

Defines the Boston and Chicago clusters and checks connectivity with them.

Adds a router and modifies a router interface.

Pulls zone data from the local clusters to create a zone distribution.

Creates a subnet and policy, and pulls address space, to configure DHCP failover pairs in Boston and Chicago.

Create the Regional Cluster Administrator

The regional superuser first creates the example-regional-administrator, defined with groups, to perform cluster and user administration.


Step 1 Log in to the regional cluster as superuser (usually admin).

Step 2 Click Administration, then Administrators to open the List/Add Administrators page.

Step 3 Enter example-regional-admin in the Name field, then examplereg in the Password field.

Step 4 Multiselect central-cfg-admin-group (for cluster administration) and regional-admin-group (for user administration) in the Groups drop-down list.

Step 5 Click Add Administrator.


Create the Central Configuration Administrator

The example-regional-admin next logs in to create the example-cfg-admin, who must have regional configuration and address management capabilities.


Step 1 Log out as superuser, then log in as example-regional-admin with password examplereg. Note that the administrator has all but host and address space administration privileges.

Step 2 Click Administration, then Administrators to open the List/Add Administrators page.

Step 3 Enter example-cfg-admin in the Name field, then cfgadmin in the Password field.

Step 4 Multiselect central-cfg-admin-group and regional-addr-admin-group in the Groups drop-down list (see Figure 4-15).

Figure 4-15 Adding a Regional Administrator (Regional)

Step 5 Click Add Administrator. The example-cfg-admin now appears with the two groups assigned.


Add the Address Space and Router Licenses

The example-regional-admin must add the appropriate licenses.


Step 1 As example-regional-admin, click Administration, then Licenses.

Step 2 Obtain the license keys for the address space and router licenses as part of your software distribution.

Step 3 On the List/Add Product Licenses page, enter the address space license key, then click Add License.

Step 4 Enter the router license key, then click Add License.


Create the Local Clusters

The example-cfg-admin next creates the two local clusters for Boston and Chicago.


Step 1 Log out as example-regional-admin, then log in as example-cfg-admin with password cfgadmin.

Step 2 Click Clusters, then Cluster List.

Step 3 On the List Server Clusters page, click Add Cluster.

Step 4 On the Add Server Cluster page, create the Boston cluster based on data provided by its administrator:

a. Enter Boston-cluster in the name field.

b. Enter the IP address of the Boston server in the ipaddr field.

c. Enter example-cluster-admin in the admin field, then exampleadmin in the password field.

d. Enter in the scp-port field the SCP port to access the cluster as set at installation (1234 by default).

e. Enter in the http-port field the HTTP port to access the cluster (8080 by default) (see Figure 4-16).

f. Click Add Cluster.

Step 5 Create the Chicago cluster in the same way, except use Chicago-cluster in the name field, enter the remaining values based on data provided by the Chicago administrator, then click Add Cluster. The two clusters should now appear on the List Server Clusters page.

Step 6 Confirm the cluster connectivity—Click Cluster Tree. The created server clusters should appear with their servers listed on the View Tree of Server Clusters page.

Step 7 Connect to the Boston cluster—Click the Go Local icon () next to Boston-cluster. If this opens the local cluster's Manage Servers page, this confirms the administrator's connectivity to the cluster. To return to the regional cluster Web UI, click the Go Regional icon ().

Step 8 Connect to the Chicago cluster to confirm the connectivity in the same way.

Step 9 Confirm that you can replicate data for the two forward zones from the Boston cluster synchronization:

a. Click Replica Data.

b. On the View Replica Class List page, click Boston-cluster in the Select Cluster list.

c. In the Select Class list, click Forward Zones.

d. Click the Replicate icon () in the Replicate Data column.

Figure 4-16 Adding a Server Cluster (Regional)

e. Click View Replica Class List. On the List Replica Forward Zones for Cluster page, you should see the boston.example.com and example.com zones.


Add a Router and Modify an Interface

The example-cfg-admin next takes over at the regional cluster to add a router and modify one of its interfaces to configure the DHCP relay agent. Adding the router pulls in the subnets already defined in the router configuration. This should occur now to prevent overlapping subnets and router synchronization errors when you add additional address space. (Because the routers define the physical network, it is preferable to save these definitions as opposed to saving those possibly conflicting definitions present in the DHCP configuration.)


Note Skip this section if a router is not available or the router license is not installed.



Step 1 As example-cfg-admin, on the Main Menu page, click Routers, then Router List.

Step 2 On the List Routers page, click Add Router.

Step 3 On the Add Router page, add the router based on data from its administrator:

a. Give the router a distinguishing name in the name field. For this example, enter router-1.

b. Because this router is a Cisco uBR7200 router, choose Ubr72xx in the Router Type drop-down list.

c. Enter the router's IP address in the address field.

d. Enter the router administrator's username in the username field.

e. Enter the router administrator's enable password in the enable field (see Figure 4-17).

Figure 4-17 Adding a Router (Regional)

f. Click Add Router. The router should now appear on the List Routers page.

Step 4 Confirm that the router is created—Click Router Tree to view the hierarchy of router interfaces for router-1 on the View Tree of Routers page.

Step 5 Configure a DHCP relay agent for the router:

a. Click one of the interface names on the View Tree of Routers page to open the Edit Router Interface page. (Alternatively, from the List Routers page, click the Interfaces icon () associated with the router, then click the interface name on the List Router Interfaces for Router page.)

b. On the Edit Router Interface page, enter the IP address of the DHCP server in the ip-helper field.

c. Click Modify Router Interface at the bottom of the page.

Step 6 Confirm with the router administrator that the DHCP relay agent was successfully added.


Add Zone Management to the Configuration Administrator

Because there are no zones set up at the Chicago cluster, the example-cfg-admin can create a zone at the regional cluster to make it part of the zone distribution. However, the example-regional-admin must first modify the example-cfg-admin to be able to create zones.


Step 1 Log out as example-cfg-admin, then log in as example-regional-admin.

Step 2 Click Administration, then Administrators.

Step 3 On the List/Add Administrators page, click example-cfg-admin.

Step 4 On the Edit Administrator page, click central-dns-admin-group in the Groups Available list, then move it (using <<) to the Selected list. The Selected list should now have central-cfg-admin-group, regional-addr-admin-group, and central-dns-admin-group.

Step 5 Click Modify Administrator. The change should be reflected on the List/Add Administrators page.


Create a Zone for the Local Cluster

The example-cfg-admin next creates the chicago.example.com zone for the zone distribution with the Boston and Chicago zones.


Step 1 Log out as example-regional-admin and log in as example-cfg-admin.

Step 2 On the Main Menu page, click DNS, then Forward Zones.

Step 3 On the List Forward Zones page, enter chicago.example.com in the Name field.

Step 4 Click Add Zone.

Step 5 On the Add Zone page, enter:

a. Serial Number—1.

b. Nameserver—ns1.

c. Contact E-mail—hostmaster.

d. Nameservers—ns1 (click Add Nameserver).

e. Click Add Zone.

Step 6 Click Reverse Zones.

Step 7 On the List Reverse Zones page, create the 60.168.192.in-addr.arpa reverse zone for the Chicago zone, with the proper attributes set.


Pull Zone Data and Create a Zone Distribution

The example-cfg-admin next pulls zone data from Boston and Chicago and creates a zone distribution.


Step 1 As example-cfg-admin, click Zone Distributions.

Step 2 On the List/Add Zone Distributions page, pull the zone from the replica database:

a. Click Pull Replica Zone Data.

b. On the Select Pull Replica Zone Data page, leave the Data Synchronization Mode defaulted as Update, then click Report to open the Report Pull Replica Zone Data page.

c. Notice the change sets of data to pull, then click Run.

d. On the Run Pull Replica Zone Data page, click OK.

Step 3 On the List/Add Zone Distributions page, notice that the Boston cluster zone distribution is assigned an index number (1) in the Name column. Click the number.

Step 4 On the Edit Zone Distribution page, in the Primary Server field, click Boston-cluster. (The IP address of the Boston-cluster becomes the first master server in the Master Servers list.)

Step 5 Because we want to make the Chicago-cluster DNS server a secondary server for the Boston-cluster:

a. Click Add Server in the Secondary Servers area.

b. On the Add Zone Distribution Secondary Server page, choose Chicago-cluster in the Secondary Server drop-down list.

c. Click Add Secondary Server.

Step 6 On the Edit Zone Distribution page, in the Forward Zones area, move chicago.example.com to the Selected list.

Step 7 In the Reverse Zones area, move 60.168.192.in-addr.arpa to the Selected list.

Step 8 Click Modify Zone Distribution.


Create a Subnet and Pull Address Space

The example-cfg-admin next creates a subnet at the regional cluster. This subnet will be combined with the other two pulled subnets from the local clusters to create a DHCP failover server configuration.


Step 1 As example-cfg-admin, click Address Space, then Subnets to open the List/Add Subnets page (see Figure 4-5). You should see the subnets created by adding the router (in the "Add a Router and Modify an Interface" section).

Step 2 Create an additional subnet, 192.168.70.0/24:

a. Enter 192.168.70 (the abbreviated form) as the subnet's network address in the Address/Mask field.

b. Leave the 24 (255.255.255.0) selected as the network mask.

c. Click Add Subnet.

Step 3 Click Address Space to confirm the subnet you created.

Step 4 On the View Unified Address Space page, click Pull Replica Address Space.

Step 5 On the Select Pull Replica Address Space page, leave everything defaulted, then click Report.

Step 6 The Report Pull Replica Address Space page should show the change sets for the two subnets from the clusters. Click Run.

Step 7 Click OK. The two pulled subnets appear on the List/Add Subnets page.


Push a DHCP Policy

The example-cfg-admin next creates a DHCP a policy, then pushes it to the local clusters.


Step 1 As example-cfg-admin, click DHCP, then Policies.

Step 2 On the List DHCP Policies page, click Add Policy.

Step 3 On the Add DHCP Policy page, create a central policy for all the local clusters:

a. Enter central-policy-1 in the Name field. Leave the offer time-out and grace period values as is.

b. Enter a lease period—In the DHCPv4 Options drop-down list, choose dhcp-lease-time [51] (unsigned time), then enter 2w (two weeks) for the lease period in the Value field.

c. Click Add Option (see Figure 4-18).

d. Click Add Policy. The central-policy-1 should appear on the List DHCP Policies page.

Figure 4-18 Adding a DHCP Policy (Regional)

Step 4 Push the policy to the local clusters:

a. Click Push Policy next to central-policy-1.

b. On the Push DHCP Policy Data to Local Clusters page, leave the Data Synchronization Mode as Ensure. This ensures that the policy is replicated at the local cluster, but does not replace its attributes if a policy by that name already exists.

c. Click Select All in the Destination Clusters section of the page.

d. Click << to move both clusters to the Selected field.

e. Click Push Data to Clusters.

f. View the push operation results on the View Push DHCP Policy Data Report page, then click OK.

Step 5 Confirm that the policy now exists at the local cluster:

a. Click Clusters to open the View Tree of Server Clusters page.

b. Next to Boston-cluster, click the Go Local icon () in the Connect column.

c. In the Boston cluster Web UI, click DHCP, then Policies to open the List DHCP Policies page. The central-policy-1 should appear.

d. Click the policy name to confirm the attributes set for it.

e. Click the Go Regional icon () at the top right corner of the page to return to the regional cluster.


Create a Scope Template

The example-cfg-admin next creates a DHCP scope template to handle failover server pair creation.


Step 1 As example-cfg-admin, click DHCP, then Scope Templates.

Step 2 On the List DHCP Scope Templates page, click Add Scope Template.

Step 3 Set the basic properties for the scope template—Enter or choose the following values in the fields:

a. Name—Enter scope-template-1.

b. Scope Name Expression—To autogenerate names for the derivative scopes, concatenate the example-scope string with the subnet defined for the scope. To do this, enter (concat "example-scope-" subnet) in the field (including the parentheses).

c. Policy—Choose central-policy-1 in the drop-down list.

d. Range Expression—Create an address range based on the remainder of the subnet (the second through last address) by entering (create-range 2 100).

e. Embedded Policy Option Expression—Define the router for the scope in its embedded policy and assign it the first address in the subnet by entering (create-option "routers" (create-ipaddr subnet 1)). (See Figure 4-19).

Figure 4-19 Adding a Scope Template (Regional)

Step 4 Click Add Scope Template. The template should appear on the List DHCP Scope Templates page.


Create and Synchronize the Failover Pair

The example-cfg-admin next creates the failover server pair relationship and synchronizes the failover pair. The DHCP server at Boston becomes the main, and the server at Chicago becomes the backup.


Step 1 As example-cfg-admin, click Failover.

Step 2 On the List DHCP Failover Pairs page, click Add Failover Pair.

Step 3 On the Add DHCP Failover Pair page, add the failover server pair—Enter or choose the following values:

a. Failover Pair Name—Enter central-fo-pair.

b. Main Server—Click Boston-cluster.

c. Backup Server—Click Chicago-cluster.

d. Scope Template—Click scopetemplate-1 (see Figure 4-20).

Figure 4-20 Adding a Failover Pair (Regional)

e. Click Add Failover Pair.

Step 4 Synchronize the failover pair with the local clusters:

a. On the List DHCP Failover Pairs page, click the Report icon () in the Synchronize column.

b. On the Report Synchronize Failover Pair page, accept Local Server as the source of network data.

c. Accept Main to Backup as the direction of synchronization.

d. Accept the operation Update.

e. Click Report at the bottom of the page.

f. On the View Failover Pair Sync Report page, click Run Update.

g. Click Return.

Step 5 Confirm the failover configuration and reload the server at the Boston cluster:

a. On the List DHCP Failover Pairs page, click the Go Local icon () next to Boston-cluster.

b. On the Manage DHCP Server page, click the Reload icon ().

c. Click the Go Regional icon () at the top of the page to return to the regional cluster.

Step 6 Confirm the failover configuration and reload the server at the Chicago cluster in the same way.