Configuration Guidelines

Cisco Network Registrar is an integrated DHCP and DNS server cluster, capable of running on an NT workstation, NT server, Solaris system, AIX, and HP/UX.

Because of the wide range of network topologies into which CNR is deployed, you should consider the following guidelines and case studies before deploying Network Registrar on your network. These guidelines are very general in nature, and cover most cases. Specific or challenging implementations of Network Registrar may require additional hardware or multiple servers.

General Guidelines

The following suggestions apply to most installations:

Select Ultra-SCSI, RAID or mirrored disk---Disk performance is critical to Network Registrar. Because server performance can be hampered by slow disk I/O, you should select servers with Ultra-SCSI disk, and choose the fastest disk RAID controller.
Set DHCP Lease Times to a relatively large value---In order to prevent leases from expiring when the DHCP client is turned off (overnight or over long weekends), set the DHCP-lease-time longer than the longest period of downtime expected for your enterprise. A DHCP lease time of 10 days should be sufficient. For more information about setting lease times, see the nrcmd policy setOption dhcp-lease-time or the Network Registrar User Guide, "Configuring Policies" section.
Use Notify / IXFR---Secondary DNS Servers can receive their data from the primary DNS server two ways: through a "full zone transfer" or through the "Notify / IXFR" (incremental transfer) technology specified in RFCs 1995 and 1996. You should use Notify / IXFR in environments in which the namespace is relatively dynamic. Using Notify / IXFR reduces the number of records that must be transferred from the primary to the secondary servers. For more information about using NOTIFY, see the nrcmd zone notify command or the Network User Guide, "Enabling NOTIFY" section.
Separate secondary DNS servers from your DHCP server---Because writing a full zone to disk can take some time, server performance can be slow when it transfers large zones to a secondary DNS server. In order to ensure that the DHCP server is not adversely affected during large zone transfers, your secondary DNS servers should run on a different cluster than your DHCP server.
Configure a separate DHCP server to run in remote segments of the WAN to ensure that the DHCP client can consistently send a packet to the DHCP server in under a second. The DHCP protocol dictates that the client receive a response to a DHCP DISCOVER or REQUEST within four seconds of packet transmission. Many clients (most notably early releases of the Microsoft DHCP stack) have actually implemented a two-second timeout.
Put backup servers on separate network segments---DNS servers are, by their very nature, redundant; however, in order to minimize client impact in the event of network failure, primary and secondary DNS servers should be on separate network segments.

Special Cases

Consider implementing these suggestions when using Network Registrar:

Set DHCP Renew Times to a small value during Network reconfiguration---Several days prior to changes in network infrastructure (gateway router addresses, DNS server addresses, etc.), set the DHCP renew time to a relatively small value. A DHCP renew time of eight hours would ensure that all DHCP clients receive changed DHCP Option parameter within one working day. For information about setting the renewal time option, see the nrcmd policy setOption dhcp-renewal-time command or the Network Registrar User Guide, "Setting DHCP Options" section.
Divide DNS and DHCP servers across multiple clusters for large deployments---If you enable this feature you should divide primary DNS and DHCP servers across two clusters, because Dynamic DNS Updates generate an additional load on the Network Registrar servers.

Cisco Network Registrar Deployment Case Studies

The following cases suggest hardware and software deployment for three different types of sites: a small LAN, a medium LAN, and a large enterprise.

Small Office Local Area Network

In a small LAN, serving fewer than 5000 DHCP clients, use mid-range Sun or NT servers. In either case, systems with EIDE disk are acceptable, though Ultra-SCSI disk is recommended. Figure 6-1 shows the hardware specifics that would be adequate for this network.

NT Recommendation: Single processor Pentium 200 or better, NT Server 4.0, 128 MB RAM, 2 GB RAID5.
Solaris Recommendation: Sun Ultra 1 or better, Solaris 2.6 128 MB RAM, 2 GB Disk.

Figure 6-1: Deployment in a Small Local Area Network

Medium Size Local Area Network

In a medium size LAN, serving 15,000 DHCP clients, use high-end Sun or NT servers. In either case, select systems with Ultra-SCSI disk. Figure 6-2 shows the hardware specifics would be adequate for this network.

NT Recommendation: Single processor Pentium 300 or better, NT Server 4.0, 128 MB RAM, 2 GB Ultra-SCSI RAID5.
Solaris Recommendation: Sun Ultra 30 or better, single processor, Solaris 2.6 128 MB RAM, 2 GB Ultra-SCSI RAID5

Figure 6-2: Deployment in a Medium Local Area Network

Large Enterprise Network

In a large enterprise network, serving 50,000 DHCP clients, use high-end Sun servers. Select systems with Ultra-SCSI disk. Figure 6-3 shows the hardware specifics that would be adequate for this network.

Solaris Recommendation: Sun Ultra 30 or better, single processor, Solaris 2.6 128 MB RAM, 2 GB Ultra-SCSI RAID5.

Figure 6-3: Deployment in a Large Enterprise

Table of Contents