Network Registrar provides the tools to configure and control the servers necessary to manage your IP address space based on underlying network concepts and protocols. This chapter aims at providing a quick overview of and the terminology underlying these concepts and protocols.

Table 2-1 lists the topics in this chapter and their associated sections.

Table 2-1: Network Registrar Network Concepts and Protocols

If you want to learn about...	Go to...

Domain Name System (DNS)	"Domain Name System" section
Dynamic Host Configuration Protocol (DHCP)	"Dynamic Host Configuration Protocol" section
Dynamic DNS update	"Dynamic DNS Update" section
DHCP server failover	"DHCP Failover" section
Client-class and class quality of service	"Client-Class Quality of Service" section
Trivial File Transfer Protocol (TFPT)	"Trivial File Transfer Protocol" section

Domain Name System

The Domain Name System (DNS) was designed in the 1980s to handle the growing number of Internet users. The Domain Name System translates names, such as www.cisco.com, into IP addresses so that computers need to be able to communicate with each other. DNS makes using Internet applications, such as the World Wide Web, easy. The process is as if, when phoning your friends and relatives, you could use their names instead of having to remember their phone numbers.

How DNS Works

To understand how DNS works, imagine a typical user, John, logging in to his computer. He launches his Web browser because he wants to view the website at a company, QuickExample. He enters the name of their website: http://www.example.com. This request causes the following to occur (see also Figure 2-1):

1. John's workstation sends a request to his DNS server asking if it knows the IP address of www.example.com.

2. The DNS server checks its database and finds that www.example.com corresponds to IP address 192.168.1.4.

3. The DNS server returns IP address 192.168.1.4 to John's browser.

4. The browser uses the IP address to locate the website.

5. The browser displays QuickExample's home page on John's monitor.

Figure 2-1: Domain Names and Addresses

Domains

John can access QuickExample's website because his DNS server knows the IP address of www.example.com. His DNS server learned the address of QuickExample's website by performing a search through the DNS domain name space. DNS was designed as a tree structure, where each domain (node in the tree structure) is named. Each domain can contain subdomains. The top-most node of the tree is the DNS root node (.), under which there are subdomains, such as .com (commercial), .edu (education), .gov (government), and .mil (military) (see Figure 2-2).

Figure 2-2: The Domain Name System Hierarchy

Each domain has a unique name, and within the domain, each subdomain name must also be unique. The fully qualified domain name (FQDN), which includes the names of all network domains leading back to the root, is unique for each host on the Internet. The FQDN for the sample domain is example.com., which indicates that the domain is example, and its parent domain is .com, whose parent domain is ".".

Learning QuickExample's Address

When John's workstation requests the IP address of the website www.example.com, his DNS server does the following (see Figure 2-3):

1. John's DNS server checks its database and cannot find the www.example.com domain, indicating that the server is not authoritative for this domain.

2. The server asks the root name server that is authoritative for the top-level (root) domain "." (dot).

3. The root server directs the query to one of the name servers for the .com domain. The .com name server knows about the subdomains of the .com domain.

4. The .com name server responds that example.com is one of its subdomains, and responds with example.com's name server's IP address.

5. John's DNS server asks example.com's name server for the location of www.example.com.

6. Example.com's name server tells John's server that www.example.com's address is 192.168.1.4.

7. John's DNS server sends this address to his Web browser, which can then connect to the address.

Figure 2-3: DNS Hierarchical Name Search

Establishing a Domain

The QuickExample company had a website that John could reach because it registered its domain with an accredited domain registrar. QuickExample also entered its domain name in the .com domain's name server's database, and requested a network number, which defines a range of IP addresses. In this case, the network number is 192.168.1.0, which comprises all addresses in the range 192.168.1.1 through 192.168.1.255.

Difference Between Domains and Zones

The domain name space is divided into areas called zones. Zones start at a domain and extend down to the leaf domains or to domains where other zones start. Zones usually represent either administrative boundaries or the data on a DNS server.

A zone is a point of delegation in the DNS tree. It contains all names from a certain point downward except those for which other zones are authoritative. Other DNS servers can ask authoritative name servers for name-to-address translation. Within an organization you can have many name servers, but Internet clients can query only those the root name servers know. The other name servers only answer internal queries.

The QuickExample company registered its domain, example.com. It established three zones: example.com, marketing.example.com, and finance.example.com. QuickExample delegated authority for marketing.example.com and finance.example.com to the DNS servers in the Marketing and Finance groups within the company. If someone queries example.com about hosts in marketing.example.com, example.com directs the query on to the marketing.example.com name server. In Figure 2-4, the domain example.com includes three zones, and the zone example.com is only authoritative for itself.

Figure 2-4: Example.com With Delegated Subdomains

QuickExample might have chosen not to delegate authority to its subdomains. In that situation, the example.com domain would consist of the example.com zone, which is authoritative for the subdomains marketing and finance (Figure 2-5). Consequently, the example.com name server would answer all outside queries about marketing and finance.

Figure 2-5: Example.com Without Delegation

As you begin to configure zones using Network Registrar (see "Configuring DNS Servers"), you will find that you need to configure a name server for each zone. Each zone has one primary server, which loads the zone's contents from a local configuration database. Each zone can also have any number of secondary servers, which load the zone contents by fetching the data from the primary server. Figure 2-6 shows a configuration with one secondary server.

Figure 2-6: Primary and Secondary Servers for Zones

Name Servers

DNS uses a client-server model, which means that the name servers contain information about a portion of the DNS database and they provide this information to clients that query the name server across the network. DNS name servers are programs that run on a physical host and store information about zones. As administrator for a domain, you set up a name server that contains the database with all the resource records describing the hosts in your zone or zones (Figure 2-7). (For more information about resource records, see "Resource Records.")

Figure 2-7: Client-Server Name Resolution

Types of Name Servers

The DNS servers provide name-to-address translation, or name resolution. They interpret the information in an FQDN to find its specific address. If a local name server does not contain the data requested in a query, it asks other name servers until it finds the specific name and address it needs. For commonly requested names, this process can go quickly because name servers continuously cache (save) the information they learn about the domain name space as the result of queries.

Each zone must have one primary name server that loads the zone contents from a local database, and a number of secondary servers, which load the zone contents by fetching a copy of the database from the primary server (Figure 2-8). This process of updating the secondary server from the primary server is called a zone transfer.

Both the primary and secondary name servers are authoritative for the zone, because they both learn about all host names within the zone from the zone's authoritative database, instead of from information learned as a result of answering queries. Both servers can be queried by clients across the network for name resolution.

Figure 2-8: DNS Zone Transfer

As you configure Network Registrar's DNS name server (see "Configuring DNS Servers"), you specify what role you want the name server and each zone to perform: the role of a primary name server for the zone, a secondary name server for the zone, or a caching-only server. The type of server is meaningful only in context to its role. A server can be a primary for some zones and a secondary for others. It can be a primary or secondary only, or it can serve no zones and just answer queries by means of its cache.

Although all servers are caching servers, because they save the information received until the data expires, a caching-only server is a server that is not authoritative for any zone. This server answers internal queries and asks other servers, who are authoritative, for the information needed. Sites create caching-only servers to relieve the traffic on the authoritative servers. Instead of every query being directed at the authoritative server, the caching-only server can handle the internal queries.

For more information about configuring a primary name server, see the "Configuring a Primary Name Server" section. For configuring a secondary server, see the "Configuring the Server as a Secondary for a Zone" section. For configuring a caching-only server, see the "Configuring a Caching-Only Server" section.

Reverse Name Servers

The DNS servers described in the previous sections are all used for name-to-address resolution. However, there are times when you know the computer address and need to learn its name. You might need this address-to-name mapping so that you can interpret certain output, such as computer log files.

The server can easily resolve names to addresses by searching through its database for the correct address, because all the data is indexed by name. Finding a domain name when you only know the address, however, would require a search of every domain name in the tree.

DNS solves this problem by supporting a domain name space that uses addresses as names. In the Internet's domain space, this portion of the name space is the in-addr.arpa domain. Within that domain there are subdomains for each network based on the network number. For consistency and natural grouping, the four octets of a host number are reversed. When you read the IP address as a domain name, it appears backwards, because the name is in leaf-to-root order.

For example, QuickExample's example domain's network number is 192.168.1.0. Its reverse zone is 1.168.192.in-addr.arpa. If you only know the DNS server address (192.168.1.1), the query to the reverse domain would find the host entry 1.1.168.192.in-addr.arpa that maps back to example.com (Figure 2-9).

Figure 2-9: Reverse Domains

Dynamic Host Configuration Protocol

All hosts seeking Internet access must have an IP address. As Internet administrator, you must do the following for every new user and for every user whose computer was moved to another subnet:

1. Select a legal IP address

2. Assign the address to the individual workstation

3. Define workstation configuration parameters

4. Update the DNS database, mapping the workstation name to the IP address

These activities are time-consuming and error prone. For these reasons, the Dynamic Host Configuration Protocol (DHCP) was created. DHCP frees you from the burden of individually assigning IP addresses. It was designed by the Internet Engineering Task Force (IETF) to reduce the amount of configuration required when using TCP/IP. DHCP allocates IP addresses to hosts. It also provides all the parameters hosts require to operate and exchange information on the Internet network to which they are attached.

DHCP localizes TCP/IP configuration information and manages the allocation of TCP/IP configuration information by automatically assigning IP addresses to systems configured to use DHCP. Thus, you can ensure that hosts have Internet access without having to configure each host individually.

How DHCP Works

DHCP was designed to make TCP/IP easier to install on large networks with little user intervention. DHCP accomplishes much of this by shifting the configuration from the individual workstation level to that of global address pools at the server level. DHCP uses a client-server model. The client software runs on the individual workstation and the server software runs on the DHCP server.

Sample DHCP User

After Beth's workstation (bethpc) is configured to use DHCP, the following occurs when she first starts her workstation (Figure 2-10):

1. Her workstation automatically requests an IP address from a DHCP server on the network.

2. The DHCP server offers her a lease that is an IP address with all the other configuration information necessary to use the Internet. Nobody else uses the leased IP address, and it is valid only for her workstation.

3. Before the IP address's lease expiration time, bethpc renews its lease, extending the expiration time. It continues to use the lease right up to its expiration if it cannot reach the server.

Figure 2-10: Hosts Request an IP Address

As long as the DHCP server has the correct configuration information, none of the workstations or servers using DHCP will ever be configured incorrectly. Therefore, there is less chance of incurring network problems from incorrectly configured workstations and servers that are difficult to trace.

Typical DHCP Administration

For you, as administrator, there is very little overhead. To use DHCP you must have at least one DHCP server on the network. After you install the DHCP server, do the following:

Define a pool of IP addresses that the DHCP server can offer to DHCP clients. You no longer need to keep track of which IP addresses are in use and which IP addresses are available. For more information about defining pools of addresses, see the "Defining and Configuring Scopes" section.
If you want a secondary server to share the distribution or to handle leases if the first DHCP server goes down, you can configure one. For details, see "Configuring DHCP Failover."
If Beth relocates to another department and her workstation moves to a different subnet, her current IP address will expire and can be leased by another workstation. When Beth starts her workstation at its new location, it leases an IP address from a DHCP server that is appropriate for the subnet on which the workstation is now located.

Leases

One of the most significant benefits of DHCP is the ability to dynamically configure workstations with IP addresses, and associate a lease with the assigned IP address. DHCP uses a lease mechanism that offers an automated, reliable, and safe method for the distribution and reuse of IP addresses in internets, with little need for administrative intervention. As system administrator, you can tailor the DHCP leasing policy to meet the specific needs of your network.

Leases are grouped together in a pool, called a scope, which defines the set of IP addresses that can be lent to requesting hosts. A lease can be reserved, which means that the host always receives the same IP address, or dynamic, which means that the host receives the next available lease in the scope.

At the QuickExample company, the DHCP server has been configured to lease IP addresses 192.168.1.100 through 192.168.1.199 (Figure 2-11).

Figure 2-11: DHCP Hosts Requesting Leases from a DHCP Server

If you do not plan to have more network devices than configured addresses for the scope, you can define long lease times, such as 1-2 weeks, to reduce network traffic and DHCP server load. For more information about leases, see the "Configuring Leases in the Scope" section.

Scopes

A scope contains a set of IP addresses for a particular subnet along with a variety of configuration parameters that tell DHCP how to operate on these addresses. You must define at least one scope for each subnet on which you want a DHCP server to supply IP addresses to DHCP clients. For more information about scopes, see the "Defining and Configuring Scopes" section.

Policies

Policies allow you to group together lease times and other configuration parameters that a DHCP server communicates to clients. Policies allow you to configure DHCP options that the DHCP server will supply to a client upon request.

Policies are especially useful if you have more than one scope at your site. You can create policies that apply to all the scopes on the current server, or create a policy for a selected scope. Policies are a convenient way of ensuring that the DHCP server supplies all the correct options for scopes and alleviates the task of specifying the information separately per scope.

In practice, you usually need to specify a router for each policy, which means that you need a policy for each scope, or a DHCP extension script that specifies the router for the subnet. For more information about policies, see the "Creating a Policy" section. For details about DHCP extensions, see the Network Registrar CLI Reference Guide.

The difference between scopes and policies (Figure 2-12) is that scopes contain information about addresses, such as which address is leasable, whether or not to ping the client before offering a lease, and other configuration options. Policies, on the other hand, contain configuration information for clients, such as the duration of the lease and the address of the local DNS server.

Figure 2-12: Scopes and Policies

Network Registrar's DHCP Implementation

The Network Registrar DHCP server provides a reliable method for automatically assigning IP addresses to hosts on your network. You can define DHCP client configurations, and use the Network Registrar database to manage assignment of client IP addresses and other optional TCP/IP and system configuration parameters. The TCP/IP parameters that can be assigned include:

IP addresses for each network adapter card in a host
Subnet masks that identify the portion of an IP address that is the physical (subnet) network identifier
Default gateway (router) that connects the subnet to other network segments
Additional configuration parameters that can be optionally assigned to DHCP clients, such as a domain name

The Network Registrar database is automatically created when you install the DHCP server software. You add data to the Network Registrar database through the GUI or the CLI as you define DHCP scopes and policies.

Dynamic DNS Update

Although DHCP frees you from the burden of distributing IP addresses, it still requires updating the DNS server with the names and IP addresses of the DHCP hosts. Dynamic DNS update automates the task of keeping the DNS database of names and IP addresses current.

With Network Registrar's Dynamic DNS update, the DHCP server can tell the corresponding DNS server when a name-to-address association occurred or changed. When a host obtains an address lease, Network Registrar tells the DNS server to add the host information. When the lease expires or when the host gives up a lease, Network Registrar tells the DNS server to remove the association.

In normal operation, you do not have to manually reconfigure DNS no matter how frequently clients' addresses change through DHCP. Network Registrar uses the host name that the client workstation provides. You also can have Network Registrar "synthesize" names for clients who did not provide them.

The procedures for configuring dynamic DNS update are described in "Configuring Dynamic DNS Update."

Effect on DNS of Obtaining a Lease

In the sample company, QuickExample, the administrator creates a scope on the DHCP server and allocates 100 leases (192.168.1.100 through 199) to the workstations on the network. Each workstation gets its owner's name. The administrator also configures the DHCP server to use dynamic DNS update and associates it with the correspondingly configured DNS server. The administrator does not need to enter any of the workstations into the DNS server's database.

Monday morning, Beth (user of bethpc) logs in and wants to access a website. After her host starts without having lease, it broadcasts a request for an IP address (Figure 2-13). Because of this request, the DHCP server:

1. Gives bethpc the next available IP address (192.168.1.125).

2. Updates her DNS server with the host name and address (bethpc 192.168.1.125).

Beth can now access the website. In addition, programs that need to translate the name of Beth's machine to her IP address, or vice versa, can query the DNS server.

Figure 2-13: Dynamic DNS Update at QuickExample Company

Effect on DNS of Releasing a Lease

Later that day, Beth learns that she needs to travel out of town. She turns off her host, which still has a leased address, but is supposed to expire after three days, as set by her DHCP policy. When the lease expires, the DHCP server:

1. Acknowledges that the IP address is now available for other users (Figure 2-14).

2. Updates the DNS server by removing the host name and address. The DNS server no longer contains information about bethpc or its address.

Figure 2-14: Relinquishing a Lease

Effect on DNS of Re-Acquiring a Lease

When Beth returns from her trip to start up her host again:

1. Her workstation broadcasts for an IP address.

2. The DHCP server checks if the host is on the right network. If so, the server issues an address. If not, the server on the right network issues the address.

3. The DHCP server updates the DNS server again with the host and address information.

DHCP Failover

Because DHCP (as described in RFC 2131) allows multiple DHCP servers, you can configure DHCP servers so that if one server cannot provide leases to requesting clients, a backup DHCP server can take over. Network Registrar provides this capability in its Failover feature.

Failover provides a high-availability DHCP service whereby you can configure two servers to operate as a redundant pair. If one server is down, the other server seamlessly takes over, and existing DHCP clients can continue to keep and renew their IP leases. Clients requesting new leases need not know or care which server is responding to their request for a lease. These clients can obtain leases even if the main server is not operational.

How Failover Works

Failover works in a partner server relationship. For failover to work between two DHCP server partners, the partners must have identical scope, lease, policy, and client-class configurations. After the servers start up, each contacts the other. After making contact, the main server provides its partner with a private pool of IP addresses that it can use in the event of a failure. The main server then updates its partner whenever it performs an operation for a DHCP client.

Under normal conditions, the main server continues to update its partner, which lets the main server respond to DHCP client requests. If a failure occurs on the main server, the backup server takes over and renews the addresses of existing clients and offers addresses to new ones. When the main server is operational again, it automatically re-integrates with its partner without administrator intervention.

The failover protocol is designed to protect against several kinds of failures:

Failure of the main server—In this case, the partner gracefully takes over the services the main server provided until the latter is operational again. Despite the fact that the main server updates its partner after responding to the DHCP client (known as a lazy update), there is no possibility of duplicate IP address allocation even if the main server fails before updating its partner.
Failure of the communication path between the main and backup servers—The backup server cannot, by itself, distinguish between a failure of the main server and the communication path to it. The failover protocol, however, is designed to operate correctly in either event. There is no possibility of duplicate IP address allocation even if both partners remain operational and each can communicate with only a subset of DHCP clients.

For a description of typical failover configurations, see "Configuring DHCP Failover."

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

1. The partners connect.

2. The main server supplies information about all existing leases to its partner.

3. The backup server requests a set of available addresses from the main server to use for new clients in case the partners lose contact.

4. The main server provides a percentage of addresses from each scope to its partner.

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

6. The main server updates its partner with the results of any client operations.

Failover State Transitions

During normal operation the DHCP failover partners transition from one state to another. The partners stay in their current state until all the actions specified on the state transition are completed. If communication fails during one of the actions, the partner simply stays in the current state and attempts a transition whenever the conditions for a transition are fulfilled.

STARTUP—The server has the opportunity to learn its partner's state before doing anything. It tries to contact its partner. When it succeeds, it immediately enters another state. A server automatically leaves the STARTUP state after a short time, typically seconds.
NORMAL—The server can communicate with its partner. This is one of the few states in which the main and backup server operations are different. The main server can respond to all client requests, while the backup server can only respond to renewal and rebinding requests.
COMMUNICATIONS-INTERRUPTED—A server cannot communicate with its partner. Main and backup servers automatically cycle (without administrative intervention) between NORMAL and COMMUNICATIONS-INTERRUPTED states as the network connection fails and recovers, or as the partner cycles between operational and non-operational. Servers cannot give duplicate addresses while they cycle between these states.
PARTNER-DOWN—Either server can enter this state. The server ignores that its partner can still operate and service a different set of clients, and simply acts as if it is the only one operating. For this reason, only one server should be in this state. The servers can then properly resynchronize and no duplicate addressing can occur.
POTENTIAL-CONFLICT—The partners are trying to re-integrate, but at least one of them is running in a state that did not guarantee automatic re-integration. The server may determine that two different clients were offered and accepted the same IP address and tries to resolve that conflict, but the two clients may not be operating.
RECOVER—The server has no information in its stable storage or is re-integrating with its partner in PARTNER-DOWN state after it comes back up. When a server is in this state, it attempts to refresh its stable storage from its partner.
RECOVER-DONE—This allows an interlocked transition for one server from RECOVER state and another from PARTNER-DOWN state, or from COMMUNICATIONS-INTERRUPTED state into NORMAL state.
PAUSED—A server can inform its partner that it will be out of service for a relatively short time and let the partner transition to COMMUNICATIONS-INTERRUPTED state immediately. The server can then begin servicing clients without interruption.
SHUTDOWN—A server can inform its partner that it will be out of service for a long time and let the partner transition immediately to PARTNER-DOWN state and take over completely.

Failover Regimes

The failover protocol operates in three regimes, which correspond loosely to the failover states. These regimes are:

Normal—The main and backup servers can communicate, and the main updates the backup with lease information.
Communications Interrupted—Neither partner can communicate with the other. The main may be down, or it may be running, but it cannot communicate with its partner.
Partner Down—The server that is running knows that its partner is not running (as described in "Configuring DHCP Failover").

Allocating Addresses

To keep your partners operating in spite of a network partition (in which both can communicate with clients, but not with each other), you must allocate more IP addresses than are needed to run a single server. You must configure the main server to allocate a percentage of the currently available addresses in each scope's address pool to its partner. These addresses are unavailable to the main server. The partner uses these addresses when it cannot talk to the main server and does not know if it is down.

How many additional addresses are needed? There is no single percentage for all environments. It depends on the arrival rate of new DHCP clients and the reaction time of your network administration staff. The backup server needs enough addresses from each scope to satisfy the requests of all new DHCP clients that arrive during the period in which the backup does not know if the main server is down.

Even during the Partner Down regime, the backup server waits for the lease expiration and maximum client lead time (how much ahead of the backup server's lease expiration the client's is) before reallocating any leases. When these times expire, the backup server:

Offers its leases from its private pool of addresses.
Offers leases from the main server's pool of addresses.
Offers expired leases to new clients.

During the day, if the administrative staff can respond within two hours to a COMMUNICATIONS INTERRUPTED state and determine if the main server is working, the backup server then needs enough addresses to support a reasonable upper bound on the number of new DHCP clients that might arrive during those two hours.

During off-hours, if the administrative staff can respond within 12 hour to the same situation (and considering that the arrival rate of previously unheard from DHCP clients is also less), the backup server then needs enough addresses to support a reasonable upper bound on the number of DHCP clients that might arrive during those 12 hours.

Consequently, the number of addresses over which the backup server requires sole control would be the greater of the two numbers, expressed as a percentage of the currently available (unreserved) addresses in each scope.

If you use client-classes (see the "Client-Class Quality of Service" section), some clients can only use some scopes and not others.

Client-Class Quality of Service

Assigning classes to clients is an important adjunct to DHCP addressing. You can use the Network Registrar client or client-class facility to provide differentiated services to users connected to a common network. You can group your user community based on administrative criteria, and then ensure that each user receives the appropriate class of service.

Although you can use Network Registrar's client-class facility to control any configuration parameter, the most common uses are for:

Address leases—How long a set of clients should keep its addresses
IP address ranges—From which lease pool to assign clients addresses
DNS server addresses—Where clients should direct their DNS queries
DNS host names—What name to assign clients
Denial of service—Whether unauthorized clients should be offered leases

One way you might use Network Registrar's client-class facility is to allow visitors access to some, but not all, of your network.

For example, when Joe, a visitor to QuickExample, tries to attach his laptop to the example.com network, Network Registrar recognizes it as being foreign. QuickExample creates one class of clients known to Network Registrar as having access to the entire network, and creates another "visitor" class with access to only a subnet. If Joe needs more than the standard visitor's access, he can register his laptop with the Network Registrar system administrator, who adds him to a different class with the appropriate service.

You do not necessarily have to assign a class to a client. If you want to treat a client individually, you can set the same access properties on a specific client basis.

The following sections describe how DHCP normally processes an address assignment, and then how it would handle it with the client-class facility in effect.

DHCP Processing Without Client-Class

To understand how you can apply client-class processing, it is helpful to know how the DHCP server handles client requests. The server can perform three tasks:

Assign an IP address
Assign the appropriate DHCP options (configuration parameters)
Optionally assign a fully qualified domain name (FQDN) and update the DNS server with that name

Here is what the DHCP server does:

1. Assigns an address to the client from a defined scope—To choose an address for the client, the DHCP server determines the client's subnet (based on the request packet contents) and finds an appropriate scope for that subnet (see the "Scopes" section).

If you have multiple scopes on one subnet or several LAN segments (known as multinetting), the DHCP server may choose among these scopes in a round-robin fashion. After the server selects a scope, it chooses an available IP address from that scope.

2. Assigns DHCP option values from a defined policy—Network Registrar uses policies to group options (see the "Policies" section). There are two types of policies: scope-specific and system default. For each DHCP option the client requests, the DHCP server searches for its value in a defined sequence:

a. If the scope-specific policy contains the option, the server returns its value to the client and stops searching.

b. If not found, the server looks in the system default policy, returns its value, and stops searching.

c. If neither policy contains the option, the server returns no value to the client and logs an error.

d. The server repeats this process for each requested option.

3. With dynamic DNS in effect, assigns an FQDN to the client—If you enabled dynamic DNS update (see the "Dynamic DNS Update" section), Network Registrar enters the client's name and address in the DNS host table. The client's name can be:

Its NetBIOS name (the default).
Its MAC address (hardware address).
A unique name using the default prefix "dhcp" or a specified prefix.

DHCP Processing With Client-Class

When you enable the client-class facility for your Network Registrar DHCP server, the request processing performs the same three tasks of assigning IP addresses, options, and domain names as described in the "DHCP Processing Without Client-Class" section, but with added capability. The DHCP server then:

1. Considers the client properties and client-class inclusion before assigning an address—As in regular DHCP processing, the DHCP server determines the client's subnet. The server then checks if there is a MAC address for this client in its database:

a. If there is no MAC address, it uses the default client specification. For example, if the client is assigned guest access, its client specification is Guest.

b. If there is no MAC address and no default client, the server handles the client through regular DHCP processing.

c. If there is a MAC address, the server checks if the client is a member of a client-class, determines its subnet based on the request packet, and applies the appropriate access properties based on its scope assignment.

The scopes must have addresses on client-accessible subnets. For example, a scope would either have a scope selection tag of Employee or Guest, but not both. In other words, there are two scopes for each subnet: one with the scope selection tag Employee, the other with Guest. Each scope has a different associated policy that provides the appropriate access rights for the user group.

2. Checks for client-class DHCP options—In regular DHCP processing, the server checks the scope-specific and system default DHCP options. With client-class, it also first checks the client-specific and client-class-specific options.

3. Provides additional FQDN assignment options—Beyond the usual name assignment process of using the host name the client requests, the server can:

Provide an explicit host name that overrides it.
Drop the client-requested host name and not replace it.
"Synthesize" a host name from the client's MAC address.

Trivial File Transfer Protocol

The Trivial File Transfer Protocol (TFTP) is a way of transferring files across the network using the UDP (datagram) protocol. Network Registrar maintains a TFTP server so that systems can provide device provisioning files to cable modems compliant with the Data Over Cable Service Interface Specification (DOCSIS) standard. The TFTP server buffers the DOCSIS file in its local memory as it sends the file to the modem. When the TFTP transfer is completed, the file is flushed from local memory.

Here are some of the features of the Network Registrar TFTP server:

Complies with RFCs 1350 and 1123
Includes a high performance multi-threaded architecture
Is configurable and controllable using the CLI (see the tftp command in the Network Registrar CLI Reference Guide for details)
Includes flexible path and file access controls
Includes audit logging of TFTP connections and file transfers
All non-Network Registrar TFTP files are storable in the install-path/data/tftp directory

Table of Contents