DNS queries typically arrive from many different clients and requests from the same client may use different source ports. With thousands of queries per second, the number of these different sources can be large and if a firewall is using stateful tracking, it has to keep this state and does so for a period of time. Hence, you need to assure that the firewall can hold sufficient state - given the query traffic rates and the state time interval.

Adding Local Clusters

Editing Local Clusters

Listing Related Servers for DHCP, DNS, and TCP Listener Servers

Connecting to Local Clusters

Synchronizing with Local Clusters

Replicating Local Cluster Data

Viewing Replica Data

Polling Lease History Data

Deactivating, Reactivating, and Recovering Data for Clusters

Enabling Lease History Collection

Adding local clusters to the regional cluster is the core functionality of the central-cfg-admin role.

To enable subnet utilization and lease history data collection, see Polling Lease History Data.

The minimum required values to add a cluster are its name, IP address of the machine, administrator username, and password. The cluster name must be unique and its IP address must match that of the host where the CNRDB database is located. Obtain the SCP and HTTP ports, username, and password from the local cluster administrator. The preset value at Cisco Prime IP Express installation for the SCP port is 1234 and the HTTP port is 8080.

You can also set whether you want outbound connections to local servers to be secure by setting the use-ssl attribute to optional or required. It is set to optional by default, and it requires the Cisco Prime IP Express Communications Security Option installed to be effective.

Editing local clusters at the regional cluster is the core functionality of the central-cfg-admin role.

If you have related DNS or DHCP failover servers (see the "Setting Up Failover Server Pairs" section in Cisco PrimeIP Express 8.3 DHCP User Guide), you can access the attributes for these servers.

In the web UI, if you have an equivalent administrator account at the local cluster, you can single sign-on to the local cluster Manage Servers page by clicking the Connect icon on the List/Add Remote Clusters page. To return to the regional cluster web UI, click the Return icon at the top right corner of the local cluster page. If you do not have an equivalent account at the local cluster, the Connect icon opens the local cluster login page.

Synchronization is configuring regional and local clusters so that they can work together in a unified fashion. When you synchronize:

1. The list of local servers are copied to the regional cluster.
2. A shared secret is established between the regional and local clusters for single sign-on.

Synchronization occurs once when you create a local cluster at the regional cluster. However, changes might occur at the local cluster periodically, requiring you to re synchronize with it. For example, you might change the username and password used to make local connections. Resynchronization does not happen automatically—you must click the Resynchronize icon next to the cluster name on the List/Add Remote Clusters page. The result is a positive confirmation for success or an error message for a failure.

When you upgrade the local cluster, you should also resynchronize the cluster. For synchronization to be effective, the user account specified for the local cluster must be a superuser. If you get a synchronization error message, check the local cluster to ensure that it is running properly.

Note

When you resynchronize clusters at the regional cluster, an automatic reinitialization of replica data occurs. The result is that for larger server configurations, resynchronization might take several minutes. The benefit, however, is that you do not need a separate action to update the replica data.

Replication is copying the configuration data from a local server to the regional cluster replica database. Replication needs to occur before you can pull DHCP object data into the regional server database. During replication:

1. The current data from the local database is copied to the regional cluster. This usually occurs once.
2. Any changes made in the master database since the last replication are copied over.

Replication happens at a given time interval. You can also force an immediate replication by clicking the Replicate icon on the List/Add Remote Clusters page.

You can set the automatic replication interval on the Add Server Cluster page, or adjust it on the Edit Server Cluster page, using the poll-replica-interval attribute. This interval is preset at four hours. You can also set the fixed time of day to poll replica data by using the poll-replica-offset attribute; its default value is zero hours (no offset). The poll-replica-rrs attribute controls the replication of RR data without disabling other data replication. This attribute is present in Manage Servers and Manage Clusters page and has the values - none, all, and protected. If poll-replica-rrs is set to none, no RR data will be replicated for this cluster. If unset, the CCM server setting will apply.

Caution

If the replica database is corrupted in any way, the regional CCM server will not start. If you encounter this problem, stop the regional service, remove (or move) the replica database files located in the install-path /regional/data/replica directory (and the log files in the /logs subdirectory), then restart the regional server. Doing so recreates the replica database without any data loss.

In the web UI, you can view the replica data cached in the replica database at the regional cluster by choosing View Replica Data from Servers submenu under the Operate menu. This opens the View Replica Class List page.

In the Regional web UI (Expert mode), you can clear the bad replica data without deleting/re-adding the clusters by clicking the Purge Replica icon on the List/Add Remote Clusters page. Whenever you perform purge replica, you must perform manual replication to get the replica data again.

Deactivating a cluster might be necessary if you suspect that a hard disk error occurred where configuration data could have been lost. You can deactivate the cluster, remedy the problem, recover cluster data from the replica database, then reactivate the cluster. This saves you from having to delete and then recreate the cluster with all of its data lost in the process.

Deactivating, reactivating, and recovering the data for a cluster is available only in the web UI, and you must be an administrator assigned the central-config-admin role.

Data that is not recovered (and that you need to manually restore) includes:

• Contents of the cnr.conf file (see Modifying the cnr.conf File)
• Web UI configuration files
• Unprotected DNS resource records
• Administrator accounts

  Note

  If the local secret db is lost, the old references are no longer valid, even though they are restored. To recover your passwords, you have to use central management for your admins, and then push them to your local clusters. Routers, since they have their own secrets, also need to be centrally managed and then should be re-pushed. For the local cluster partner objects, running the sync from regional will create valid objects, but the old cluster objects may need to be deleted first.

• Lease history
• Extension scripts

Note	Restoring the data to a different IP address requires some manual reconfiguration of such things as DHCP failover server pair and High-Availability (HA) DNS server pair addresses.

You can view logs and startup logs; edit the server attributes.

To view logs and startup logs, in the local cluster web UI, from the Operate menu, choose Manage Servers to open the Manage Servers page.

How Notification Works

Handling SNMP Queries

Cisco Prime IP Express SNMP notification support allows a standard SNMP management station to receive notification messages from the DHCP and DNS servers. These messages contain the details of the event that triggered the SNMP trap.

Cisco Prime IP Express generates notifications in response to predetermined events that the application code detects and signals. Each event can also carry with it a particular set of parameters or current values. For example, the free-address-low-threshold event can occur in the scope with a value of 10% free. Other scopes and values are also possible for such an event, and each type of event can have different associated parameters.

The following table describes the events that can generate notifications.

Every down trap must be followed by a corresponding up trap. However, this rule is not strictly applicable in the following scenarios:

1. If a failover partner or LDAP server or DNS server or HA DNS partner is down for a long time, down traps will be issued periodically. An up trap will be generated only when that server or partner returns to service.
2. If the DHCP or DNS server is reloaded or restarted, the prior state of the partner or related servers is not retained and duplicate down or up traps can result.

Note	Other failover partner or LDAP server or DNS server or HA DNS partner up or down traps occur only to communicate with that partner or server, and therefore may not occur when the other partner or server goes down or returns to service.

You can use SNMP client applications to query the following MIBs:

• CISCO-DNS-SERVER-MIB.my
• CISCO-IETF-DHCP-SERVER-MIB.my
• CISCO-IETF-DHCP-SERVER-EXT-MIB.my
• CISCO-NETREG-DHCPV6-MIB.my (experimental)

When the SNMP server receives a query for an attribute defined in one of these MIBs, it returns a response PDU containing that attribute value. For example, using the NET-SNMP client application (available over the Internet), you can use one of these commands to obtain a count of the DHCPDISCOVER packets for a certain address:

C:\net-snmp5.2.2\bin>snmpget -m ALL -v 2c -c public
192.168.241.39:4444.iso.org.dod.internet.private.enterprises.cisco.ciscoExperiment.
ciscoIetfDhcpSrvMIB.ciscoIetfDhcpv4SrvMIBObjects.cDhcpv4Counters.cDhcpv4CountDiscovers
 
CISCO-IETF-DHCP-SERVER-MIB::cDhcpv4CountDiscovers.0 = Counter32: 0 
C:\net-snmp5.2.2\bin>snmpget -m ALL -v 2c -c public 
192.168.241.39:4444
 1.3.6.1.4.1.9.10.102.1.3.1
 
CISCO-IETF-DHCP-SERVER-MIB::cDhcpv4CountDiscovers.0 = Counter32: 0 

Both commands return the same results. The first one queries the full MIB attribute name, while the second one queries its OID equivalent (which can be less error prone). As previously described, the OID equivalents of the MIB attributes are located in the relevant files at the following URL:

ftp://ftp.cisco.com/pub/mibs/oid/

For example, the CISCO-IETF-DHCP-SERVER-MIB.oid file includes the following OID definition that corresponds to the previous query example:

"cDhcpv4CountDiscovers" "1.3.6.1.4.1.9.10.102.1.3.1"

Here are some possible SNMP query error conditions:

• The community string sent in the request PDU does not match what you configured.
• The version in the request PDU is not the same as the supported version (SNMPv2).
• If the object being queried does not have an instance in the server, the corresponding variable binding type field is set to SNMP_NOSUCHINSTANCE. With a GetNext, if there is no next attribute, the corresponding variable binding type field is set to SNMP_ENDOFMIBVIEW.
• If no match occurs for the OID, the corresponding variable binding type field is set to SNMP_NOSUCHOBJECT. With a GetNext, it is set to SNMP_ENDOFMIBVIEW.
• If there is a bad value returned by querying the attribute, the error status in the response PDU is set to SNMP_ERR_BAD_VALUE.

Lease history data is automatically collected at any regional cluster where these feature is enabled for the DHCP server or failover pair. The default polling interval to update the regional databases is 4 hours. You can poll the servers by clicking the Lease History icon on the List/Add Remote Clusters page. For this manual polling, if the server is in a failover relationship, data is only retrieved for the subnets where the server is the main. If you have address space privileges (you are assigned the regional-addr-admin role with at least the lease-history subrole), you can query the lease history data by choosing Current Utilization or Lease History from Operate menu (see the "Running IP Lease Histories" section in Cisco PrimeIP Express 8.3 DHCP User Guide).

You can adjust the automatic polling interval for subnet utilization and lease history, along with other attributes. These attributes are set in three places at the regional cluster, with the following priority:

1. Cluster—These values override the server-wide settings, unless they are unset, in which case the server values are used. The cluster values are set when adding or editing the cluster. In the CLI, set the attributes listed in the table below, using the cluster command.
2. Regional CCM server (the preset polling interval is 4 hours)—This is set on the Edit CCM Server page, accessible by clicking Servers, then the Local CCM Server link. In the CLI, set the attributes listed in the table below using the ccm command.

Note	If lease history collection is not explicitly turned on at the local cluster DHCP server (see Enabling Lease History Collection), no data is collected, even though polling is on by default.

The polling offset attribute ensures that polling occurs at a specific hour of the day, set as 24-hour time, in relation to the polling interval. For example, if you set the interval to 4h and the offset to 6h (6 A.M.), the polling occurs at 2 A.M., 6 A.M., 10 A.M., 2 P.M., 6 P.M., and 10 P.M. each day.

Pushing Scope Templates to Local Clusters

Pulling Scope Templates from Replica Data

You can push the scope templates you create from the regional cluster to any of the local clusters. In the web UI, go to the List/Add DHCP Scope Templates page, and do any of the following:

• if you want to push a specific template to a cluster, select the scope template from the Scope Templates pane on the left, and click Push (at the top of the page). This opens the Push DHCP Scope Template page.
• If you want to push all of the available scope templates, click the Push All icon at the top of the Scope Templates pane. This opens the Push Data to Local Clusters page.

You may choose to pull scope templates from the replica data of the local clusters instead of explicitly creating them. (You may first want to update the policy replica data by clicking the Replicate icon next to the cluster name.) To pull the scope templates in the regional web UI, click the Pull Replica icon at the top of the Scope Templates pane.

Pushing Policies to Local Clusters

Pulling Policies from Replica Data

You can also push the policies you create from the regional cluster to any of the local clusters. In the regional web UI, go to List/Add DHCP Policies page, and do any of the following:

• If you want to push a specific policy to a cluster, select the policy from the Policies pane on the left, and click Push (at the top of the page).
• If you want to push all the policies, click the Push All icon at the top of the Policies pane.

You may choose to pull policies from the replica data of the local clusters instead of explicitly creating them. (In the regional web UI, you may first want to update the policy replica data by clicking the Replicate icon next to the cluster name). To pull the policies, click the Pull Replica icon at the top of the Policies pane.

Pushing Client-Classes to Local Clusters

Pushing Client-Classes to Local Clusters

You can also push the client-classes you create from the regional cluster to any of the local clusters. In the Regional web UI, go to the List/Add DHCP Client Classes page, and do any of the following:

• If you want to push a specific client-class to a cluster in the web UI, select the client-class from the Client Classes pane on the left, and click Push (at the top of the page). This opens the Push DHCP Client Class page.
• If you want to push all the client-classes, click the Push All icon at the top of the Client Classes pane. This opens the Push Data to Local Clusters page.

You may choose to pull client-classes from the replica data of the local clusters instead of explicitly creating them. (In the web UI, you might first want to update the client-class replica data by clicking the Replicate icon next to the cluster name.) To pull the client-classes, click the Pull Replica icon at the top of the Client Classes pane.

Pushing VPNs to Local Clusters

Pulling VPNs from Replica Data

You can push the VPNs you create from the regional cluster to any of the local clusters. In the Regional web UI, go to the List/Add VPNs page, and do any of the following:

• If you want to push a specific VPN to a cluster in the web UI, select the VPN from the VPNs pane on the left, and click Push (at the top of the page). This opens the Push VPN page.
• If you want to push all the VPNs, click the Push All icon at the top of the VPNs pane. This opens the Push Data to Local Clusters page.

Instead of explicitly creating VPNs, you can pull them from the local clusters. (In the regional web UI, you may first want to update the VPN replica data by clicking the Replica icon next to the cluster name.) To pull the replica data, click the Pull Replica icon at the top of the VPNs pane on the left, to open the Select Replica VPN Data to Pull page.

This page shows a tree view of the regional server replica data for the local clusters’ VPNs. The tree has two levels, one for the local clusters and one for the VPNs in each cluster. You can pull individual VPNs or you can pull all of them. To pull individual VPNs, expand the tree for the cluster, then click Pull VPN next to its name. To pull all the VPNs, click Pull All VPNs.

To pull the VPNs, you must choose a synchronization mode:

• Ensure—Ensures that the regional cluster has new data without affecting any existing data.
• Replace (preset value)—Replaces data without affecting other objects unique to the regional cluster.
• Exact—Available for “pull all” operations only. Use this with caution, because it overwrites the data and deletes any other objects unique to the regional cluster.

DHCPv4 Reservations

DHCPv6 Reservations

To create DHCPv4 reservations, the parent subnet object must exist on the regional server. If there are pending reservation edits at regional, these can be pushed to the subnet local cluster or failover pair. If the subnet has never been pushed, the parent scope is added to the local cluster or pair.

Once a subnet is pushed to a local cluster or pair, reservations are pushed to that cluster or pair. To move the scopes and subnet to another local cluster or failover pair, the subnet must first be reclaimed.

To create DHCPv6 reservations, the parent prefix must exist on the regional server. When there are pending reservation or prefix changes, you can push the updates to the local cluster.

Once a prefix is pushed to a local cluster, it can only update that local cluster. To move the prefix to another local cluster, it must first be reclaimed.

Administrator Responsibilities and Tasks

Create the Administrators

Create the Address Infrastructure

Create the Zone Infrastructure

Create a Host Administrator Role with Constraints

Create a Group to Assign to the Host Administrator

Test the Host Address Range

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.

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.

Administrator Responsibilities and Tasks

Create the Regional Cluster Administrator

Create the Central Configuration Administrator

Create the Local Clusters

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

The regional administrators have the following responsibilities and tasks:

• example-regional-admin—Created by the superuser at the San Jose regional cluster, who creates the example-cfg-admin.
• 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.