|
|
You can write extensions to affect the way the Network Registrar DHCP server handles requests, the way it responds to requests, and to change the behavior of Network Registrar after an extension is run.
This chapter describes the extension points to which you can attach extensions. For information about the DHCP extension dictionaries, see the "DHCP Extension Dictionary Entries" appendix.
You can alter and customize the operation of the Network Registrar DHCP server through the use of extensions, which are programs that you can write in either Tcl or C/C++.
You need to complete these procedures to create an extension for use in the DHCP server:
For example, suppose you have an unusual routing hub that uses BOOTP for its configuration. This device, however, sends out a BOOTP request with an Ethernet hardware type (that is, 1) and a particular MAC address in the chaddr field. It then sends out another BOOTP request with a hardware type of token ring (that is, 6), and the same MAC address in the chaddr field.
Specifying two different hardware types causes the DHCP server to allocate two IP addresses to the device because the DHCP server distinguishes between a MAC address with hardware type of 1 and a hardware type of 6. The DHCP server sees these as different devices.
In this case, you might want to write an extension that prevents the DHCP server from handing out two different addresses to the same device.
There are often many solutions to a single problem. When choosing the type of extension to write, you should first consider rewriting the input DHCP packet. This is good approach, because it avoids any need for knowledge of the internal processing of the DHCP server.
You can solve the problem of the two IP addresses in two different ways:
This example illustrates a second useful approach to modifying the DHCP server's behavior---rewriting the DHCP response packet before it is returned to the DHCP client.
One reason to use extensions is to transmit information available only within the DHCP server to the external environment. The extension point that you can use for this purpose is the post-send-packet, which is called after the transmission of any DHCP response packet to a DHCP client. For more information about this extension point, see the "Send the Packet" section later in this chapter.
To decide on the appropriate extension point to perform the task, you have to understand how the DHCP server processes client requests and generates DHCP responses. For more information about processing requests, see the "Extension Points and DHCP Request Processing" section later in this chapter.
The example task uses the first extension point after the DHCP server receives the request packet (post-packet-decode), and the last extension point before the DHCP server transmits the response packet to the DHCP client (pre-packet-encode). For more information about post-packet-decode, see the "Decode the Packet" section later in this chapter. For more information about pre-packet-encode, see the "Gather the Response Packet Information" section later in this chapter.
You can write extensions in Tcl or in C/C++. The capabilities of each language (as far as the DHCP server is concerned) are similar, although the API is slightly different to support the two very different approaches to language design.
In general, choosing Tcl allows you to write an extension quickly with less difficulty. If the extension is short, then the interpreted nature of Tcl will not have a serious affect on the performance. When you write an extension in Tcl, you are less likely to introduce a bug that will crash the server.
Choosing to write the extension in C/C++ on the other hand, provides the maximum possible performance and flexibility including communicating with external processes. The complexity of the C/C++ API is greater, and the possibility of a bug in the extension crashing the server is more likely than with Tcl.
You need to be aware of the following items independent of whether you choose to write your extensions in Tcl or C/C++.
You need to define the extension to the DHCP server as a file and a routine within that file. You then need to attach the extension to one or more of the DHCP server extension points. When the DHCP server reaches that extension point, it calls the routine defined by the extension. When this routine returns, the return defines success or failure. You can configure the DHCP server to drop a packet on the failure of an extension.
You can configure one file (Tcl source file or C/C++ .dll or .so file) as multiple extensions to the DHCP server by specifying a different entry point for each configured extension.
The DHCP server calls every routine entry point with at least three arguments, which are three dictionaries: request, response, and environment. Each dictionary is a representation of a key-value pair. The extension can retrieve specific data items from the DHCP server by performing a get method on a dictionary for a particular data item. The extension can alter data items by performing a put operation on the same named data item. Although you cannot use all dictionaries at every extension point, the calling sequence for all routines is the same for every extension point. (The extension encounters an error if it attempts to reference a dictionary that is not present at a particular extension point.) For more information about the data items present in each dictionary, see the "Overview of the Environment Dictionary" and the "Request and Response Dictionaries" sections later in this chapter.
The environment dictionary contains control information passed between the DHCP server and extension.
The request and response dictionaries support data that is string-valued, integer-valued, IP address-valued, and blob-valued (a sequence of bytes, not zero terminated). The environment dictionary supports only string-valued data.
You can also use the environment dictionary to communicate between two extensions running at different extension points. When the first extension point (at which some extension is configured) is encountered, the DHCP server creates an environment dictionary. The environment dictionary is the only dictionary in which the names of the allowable data items are not fixed by the DHCP server. It allows an extension to insert any string-valued data item. Every extension point in the flow of control between the request and response for the DHCP client (that is, all of the extension points except pre-dns-add-forward), share the same environment dictionary. An extension may determine that some condition exists and place a sentinel in the environment dictionary so that a subsequent extension can avoid determining that the same condition.
In the previous example, the extension at the post-packet-decode extension point determines that the packet was the interesting one from a particular manufacturer's device, BOOTP, and token ring, and then rewrites the hardware type from token ring to Ethernet. It also places a sentinel in the environment dictionary, and then a very simple extension at the pre-packet-encode extension point rewrites the hardware type back to token ring.
Each dictionary has associated utility methods that include the ability to reset the trace-level for an extension, and log values into the output file.
There is an additional extension point that is called whenever the DHCP server configures or unconfigures the extension. This occurs whenever the DHCP server is started or stopped. (A reload is a stop and then a start.) This entry point has the same signature as the other entry points for the extension, but you can only use the environment dictionary at this extension point. Configure the init-entry extension point by implicitly by defining an init-entry on an already configured extension.
These arguments are present for both the configure and unconfigure calls of the init-entry entry point. The extension-point name for the configure call is initialize, and for the unconfigure call is uninitialize.
There are many reasons why an extension can fail to configure: the file may not be found, the entry point or init-entry point may not appear in the file, or the extension itself can return failure from an init-entry call. If the extension returns failure from an init-entry, the extension will fail to configure.
By itself a failure for an extension to configure is not fatal, and will not prevent the DHCP server from starting. If, however, the server tries to configure an extension point using the extension that failed, the configuration for that extension point will fail. If DHCP server fails to configure any extension points, then the server will not start. To debug the configuration process, you can configure your extension and the init-entry point without attaching it to an extension point. When you have completed that process, you can attach your extension to an extension point.
The DHCP server only recognizes extensions when it initially configures itself at start or reload time.You can change an extension, or the configuration for extensions in general, but until you have reloaded or restarted the server, the changes have no effect. Forgetting to reload the DHCP server can be a frequent source of errors while debugging extensions.
The reason Network Registrar requires a reload is to ensure minimum processing impact by preloading extensions and getting them ready at server configuration time. While this approach is useful in production mode, it might cause some frustration when you are debugging extensions.
If you choose to write your extensions in Tcl, you need to understand the Tcl API, how to handle errors and boolean variables, and how to initialize Tcl extensions.
Every Tcl extension has the same routine signature:
proc yourentry { request response environ } {
#your code goes here
}
In order to operate on the data items in any dictionary, you must treat these arguments as commands. To get the giaddr of the input packet, enter:
set my_giaddr [ $request get giaddr ]
This sets the Tcl variable my_giaddr to the string value of the giaddr in the packet (for example, 10.10.1.5 or 0.0.0.0).
You can rewrite the giaddr in the input packet by using the Tcl statement:
$request put giaddr "1.2.3.4"
In order to allow one routine entry to be configured for multiple different extension points and to alter its behavior depending on the extension point from which it is called, the ASCII name of the extension point is passed in the environment dictionary under the key extension-point.
For some sample Tcl extensions, see the following Network Registrar directories:
Remember that you will generate a Tcl error if you reference a dictionary that is not available; if you reference a dictionary data item that is not available; or if you request a put operation on an invalid data item (for example, an IP address of "1.2.3.a" is not acceptable).
In these cases, the extension immediately fails unless you surround the statement with a catch { } error statement:
catch { $request put giaddr "1.2.3.a" } error
In the environment dictionary, the boolean variables are string-valued and have a value of true or false, and the DHCP server expects an extension to set the value to true or false.
To configure an extension, write the extension and place it in the extensions directory. For UNIX, this is /opt/nwreg2/extensions/dhcp/tcl and for Windows NT, this is \Network Registrar\Registrar\extensions\dhcp\tcl.
When the DHCP server configures a Tcl extension during start-up, it reads the Tcl source file into a Tcl interpreter. Any syntax errors that appear in the source file that would cause the Tcl interpreter to be unable to load the file cause the DHCP server to fail to configure the extension. Typically, the DHCP server will generate an error traceback in the log file from Tcl to help you to determine the location of the error.
Tcl extensions support the init-entry entry point, and the arguments supplied in the init-args parameter to the command line appear in the environment dictionary associated with the key arguments.
Multiple Tcl interpreters may be running within the DHCP server for performance, each in its own Tcl context. The Tcl extension will be called once at the init-entry point for every Tcl context (interpreter) running in the DHCP server. You should ensure that your Tcl extension's init-entry is coded to be robust given multiple calls.
There is no way for any information to be passed between the Tcl contexts, but the init-entry can initialize global Tcl variables in each Tcl context (interpreter) that can then be accessed by any Tcl extension regardless of the Tcl interpreter in which it runs.
The Tcl interpreters are shared among all of the Tcl extensions, so if your Tcl extension initializes global variables or defines procedures, ensure that these do not conflict with some other Tcl extensions' global variables or procedure names.
All DHCP C/C++ extensions are called dex extensions, which is short for DHCP Extension.
The routine signature for both the entry and init-entry routines for the C/C++ API is as follows:
typedef int (DEXAPI * DexEntryPointFunction)( int iExtensionPoint, dex_AttributeDictionary_t* pRequest, dex_AttributeDictionary_t* pResponse, dex_EnvironmentDictionary_t* pEnviron );
In addition to pointers to three structures, the integer value of the extension point is one of the parameters of each routine.
The C/C++ API has been specifically constructed so that you do not have to link your shared library with any Network Registrar DHCP server files. The entry to your routine is configured when the extension is configured, and then the necessary call-back information for the operations to be performed on the request, response, and environment dictionaries is supplied in the structures that comprise the three dictionary parameters passed to your extension routine.
The DHCP server returns all binary information in network order, which is not necessarily properly aligned for executing architecture.
Many C/C++ routines are available that use types, for example, getByType(). These routines are designed for use in performance-sensitive environments. These routines are useful because the extension can acquire pointers to types once, for example, in the init-entry point, and then use the pointers instead of string-valued names when calling the routines of the C/C++ API. Using types in this manner removes one hash-table lookup from the extension processing flow of execution, which should improve (at least fractionally) the performance of any extension.
The directory (UNIX---/opt/nwreg2/examples/dhcp/dex and for Windows NT---\Network Registrar\Registrar\examples\dhcp\dex) contains example C/C++ extension code, as well as a short Makefile that has been designed to build the example extensions. In order to build your own extensions, you need to modify this file. It has sections for Microsoft Visual C++ V5.0, GNU C++, and SunPro C++. Move the comment lines in order to configure the file for your environment.
Your extension needs to reference the include file dex.h. This file contains the information your program will need to use the C/C++ API. When building C/C++ extensions on Windows NT, remember to add your entry points to the .def file.
After you build the .dll or .so file (all dex extensions are shared libraries), you need to move them into the (UNIX---/opt/nwreg2/examples/dhcp/dex and for Windows NT---\Network Registrar\Registrar\examples\dhcp\dex) directory. You can then configure them.
Because the .dll and .so files are active when the server is running, it is not a good idea to overwrite them. After the server is stopped, the .dll and .so files are not in use and you can overwrite them with newer versions.
The C/C++ extension interface routines return pointers into DHCP server memory in two formats. The first is a char* pointer to a series of bytes. The second is a pointer to a structure called an abytes_t, which is a structure that provides a pointer to a series of bytes with an associated length (it is defined in dex.h).
In both of these cases, the pointers into DHCP server memory are valid for the duration of the execution of the extension running at that extension point. They are also valid for the rest of the extension points in the series processing this request. An abytes_t pointer returned in the post-packet-decode extension point is still valid in the post-send-packet extension point. The pointer is not, however, valid in the pre-dns-add-forward extension point because this extension point is not part of the cycle of request-response processing, but is handled by a different subsystem. The duration of validity of the pointers returned into DHCP server memory is the same as the duration of validity of information that is placed into the environment dictionary.
There is an exception to this statement. One C/C++ routine, getType, returns a pointer to an abytes_t that references a type. These pointers are valid through the entire life of the extension. Typically you would call this routine in the init-entry extension point and save the pointers to the abytes_t structures that define the types in the static data of the shared library. Pointers to abytes_t structures returned by getType are valid from the init-entry call for the initialization until the init-entry call for uninitialization.
The file dex.h defines two extension point values that are passed as the extension points for the configure and unconfigure calls: DEX_INITIALIZE for configure and DEX_UNINITIALIZE for unconfigure.
In addition, the environment dictionary value of the extension-point is initialize or uninitialize in each call.
The Network Registrar DHCP server has extension points to which you can attach your own extensions. They are named with descriptive names that indicate where in the processing flow of control they are used.
Because the extension points are tied to the processing of input requests from DHCP clients, it is helpful to understand how the DHCP server handles requests.
To process a request, the DHCP performs the following processes:
These processes are explained in the following sections. The extension points are indicated by italics.
After the DHCP has passed this extension point, it stores all information from the packet in several internal data structures in order to make subsequent processing more efficient.
If you have enabled client-class processing, the DHCP server performs it at this stage.
At this stage, the DHCP server determines the type of the request and builds an appropriate response template based on the type of the input request. For example, if the input request is a DHCP OFFER, the DHCP server creates a DISCOVER response to perform the processing. If the input request is a BOOTP request, then the DHCP server creates a BOOTP response to perform the response processing.
The DHCP server must determine the subnet from which every request originated and map that into a set of address pools or scopes that contain IP addresses.
Internal to the DHCP server is the concept of a network, which, in this context, refers to a segment or physical network. Within the DHCP server every scope belongs to a single network. Some scopes are grouped together on the same network because their network numbers and subnet masks are identical, others are grouped because they are related through the primary-scope pointer.
The Network Registrar DHCP server does the following to determine which network to use to process a DHCP client request:
After the DHCP server establishes the network, it searches the hash table held at the network level to see if this client's client-id is already known to this network. Already known, in this context, means that this client has previously received an offer or a lease on this network, and the lease has not been offered or leased by a different client because that time. A current lease or an available expired lease will appear in the network-level hash table. If the DHCP server finds a lease, then it proceeds to the next step, which is to serialize all requests for the same IP address.
If the DHCP server does not find a lease, and if this is a BOOTP or DHCP discover request, then the DHCP server looks for a reserved lease from a scope in this network. If it finds a reserved lease, then the server checks whether the scope and lease are both acceptable. The following must be true of the reserved lease and the scope that contains it:
If the reserved lease is acceptable, the server proceeds to the next step, which is to serialize all requests for the IP address.
Having failed to find an existing or reserved lease for this client, the server now attempts to find any available IP addresses for this client.
The general process the DHCP server uses is to scan all of the scopes associated with this network in round-robin order, looking for one that is acceptable for this client and also has available addresses.
An acceptable scope has the following characteristics:
Because multiple DHCP requests can be in process simultaneously for one client and one lease, they must be serialized at the level of the lease. They are queued on the lease and processed in order of queueing.
The DHCP server now determines if the lease is (still) acceptable for the client. If this is a newly acquired lease for a first-time client, it will be available, but if the DHCP server is processing a renewal for an existing lease, the acceptability criteria may have changed because the lease was granted and needs to be checked again.
If the client has a reservation that is different from the current lease, the server first determines if the reserved lease is acceptable. The criteria for release acceptability are as follows:
If the reserved lease meets all of this criteria, then the DHCP server considers the current lease unacceptable.
If there is no reserved lease for this client, or the reserved lease did not meet the criteria for acceptability, then the DHCP server examines the current lease for acceptability. The criteria for acceptability are as follows:
At this point in the DHCP server processing, you can use the fifth extension point:
Upon determining that a lease is unacceptable, the DHCP server takes different actions depending on the particular DHCP request currently being processed:
In this stage of processing, the DHCP server collects all the information to send back in the DHCP response, and determines the address and port to which to send the response.
In this stage, the DHCP encodes the information in the response data structure into a network packet.
If this DHCP client requires DNS activity, the DHCP server queues a DNS work request to the DNS processing subsystem in the DHCP server. That request runs whenever it can, but generally not before sending the packet to the DHCP client. For more information about how the DHCP server processes the request, see the "Processing DNS Requests" section later in this chapter.
At this stage the DHCP server ensures that the on-disk copy of the information is up-to-date with respect to the IP address before proceeding.
The DHCP server sends the packet to the DHCP client.
If it might take a long time to connect to the external environment, then the extension should use a separate thread for improved performance. The DHCP server possesses only a limited number of threads that are used for request processing, and if some (or worse) all of them are stalled in an extension waiting on some external condition, the DHCP server's performance suffers. There are no guidelines for how long is long, but in general, if the extension completes within two or three seconds it should not impact the performance of the DHCP server. More than three seconds is definitely too long, and you should structure the extension to add a request to an internal queue within the extension code and immediately return. Use a separate thread owned by the extension to process this queue.
You can create a separate thread in the initialization call to the C/C++ extension's init-entry routine. Remember to destroy the thread on the corresponding init-entry uninitialization call.
When adding a request to an internal queue for processing later, be sure to copy the data returned by dictionary get requests, because any pointers returned in C/C++ typically will be invalid by the time the thread processing the queue runs.
The DHCP server does the following to processes DNS work item requests:
Every extension is defined as a routine with three arguments. These arguments represent the request dictionary, the response dictionary, and the environment dictionary. Not every dictionary is available to every extension.
Table 4-1 shows the extensions points and the dictionaries that are available to them.
| Extension Point | Dictionary |
|---|---|
Request and Environment | |
Request and Environment | |
Request and Environment | |
Request, Response, and Environment | |
Request, Response, and Environment | |
Request, Response, and Environment | |
Environment | |
Environment | |
Init-entry: uninitialize | Environment |
Each of the three dictionaries consists of name-value pairs. The environment dictionary, which is available to every extension point, is the simplest dictionary. The environment dictionary consists of a set of name-value pairs in which the name and the value are both strings. The request and response dictionaries are more complex and their data is typed. When you set a value in one of these dictionaries, you need to match the data type to the value.
You can use the dictionaries for getting, putting, and removing values.
The DHCP server uses the environment dictionary to communicate with extensions in different ways at different extension points. At some extension points, the server places information in the environment dictionary for the extension to modify, while in others the extension may place values in the environment dictionary to control the flow or data after the extension has completed its processing.
The environment dictionary is unique in that an extension may put any name-value pair it wishes into the environment dictionary. Although you will not get an error for using undocumented name-values, the server will not recognize them.
The DHCP server creates the environment dictionary when a DHCP request arrives, and the dictionary remains with that request through the processing. An extension that runs at the post-packet-decode extension point may put information into the environment dictionary and then an extension run at the pre-packet-encode extension point might read that information from the dictionary.
The following data items are always valid in the environment dictionary:
These dictionaries have a fixed set of accessible names; however, not all of the names are accessible from every extension point. These dictionaries make internal server data structures available to the extension for read/write or in some cases, read-only access. Each data item has a particular data type. If you do not specify the correct data type (for C/C++ extensions) on a put operation, or if the DHCP server cannot convert it to the correct data type (for Tcl extensions), then the extension will encounter an error.
The request dictionary is available at the beginning of the processing of a request. After the DHCP server creates a response, both the request and response dictionaries are available. Accessing a response dictionary before it is available generates an error.
In general, you cannot use an extension to change information that is configurable in the server. In some cases, however, you can use an extension to change configured information, but only for the duration of the processing for only that single request.
The DHCP protocol is a request-response UDP-based protocol and the stimulation for a DHCP server operation is usually a DHCP request from a client. The result is usually a DHCP response to be sent back to that client.
The DHCP extension facility makes the information input in the DHCP request available to extensions at most of the extension points, and the information to be sent as a response to a DHCP request available at the pre-packet-encode extension point.
In addition to this DHCP packet-based information, there is information that the DHCP server uses when processing DHCP requests. This information is associated with either the DHCP request or the DHCP response as part of the architecture of the DHCP server. Much of this information is also made available to extensions, and much of it can be both read and written, in many cases altering the processing algorithms of the DHCP server.
The request and response dictionaries contain two classes of information in each dictionary, as shown in Figure 4-1. They contain decoded packet data items as well as other request or response associated data items. The decoded packet data items are those data items that are directly contained in or derived from the DHCP request or DHCP response. Access to the decoded packet data items allows you to read and, in some cases, rewrite the DHCP request and DHCP response packet.
You can access information from the DHCP request packet such as the giaddr, ciaddr, and all of the incoming DHCP options by using the decoded packet data items in the request dictionary.
You can set the ciaddr, giaddr, add and remove DHCP options in the outgoing DHCP response by accessing the decoded packet data items in the response dictionary.
It is important to realize that access to the packet information provided by the decoded packet data items is not all of the information available to the you. In the description of each extension point, the specific data items available to that extension point are listed. Because the decoded packet data items are always accessible or not as a group, they are listed as a group, which is the decoded packet data items. For a description of these data items, see the "Decoded DHCP Packet Data Items" section in the "DHCP Extension Dictionary Entries" appendix.
You access DHCP options by name. If the option is not present, then no data is returned for that option. If you place an option into the decoded request or decoded response, it replaces any option with the same name already in the decoded request or decoded response unless in the put operation the data is specifically supposed to be appended to existing data.
Some DHCP options may have multiple values, for example, the routers option may have one or more IP addresses associated with it. These multiple values are accessed using indexed operations on the option name.
There is one option, dhcp-parameter-request-list, that is handled in two ways:
You can get or put it using either name. The DHCP server handles the dhcp-parameter-request-list (and its blob variant as well) differently in the response dictionary than in the request dictionary. When it is accessed in the request dictionary, this option is a DHCP option in the request dictionary. In the response dictionary, however, special processing takes place.
You can use the dhcp-parameter-request-list option in the response dictionary to control the order of the options returned to the DHCP or BOOTP client. When you put the dhcp-parameter-request-list option into the response dictionary, the DHCP server reorders the existing options so that the ones listed in the dhcp-parameter-request-list are first and in the order that they appear in the dhcp-parameter-request-list. The remaining options appear in their current order after the last ones that were in the dhcp-parameter-request-list. The DHCP server retains the dhcp-parameter-request-list, and uses it to order any future options that are put into the response (until it is replaced by a new dhcp-parameter-request-list).
When an extension does a get operation for the dhcp-parameter-request-list in the response dictionary, instead of looking into the decoded response packet to find a dhcp-parameter-request-list option, the DHCP server will synthesize one that contains the list of all options currently in the decoded response packet.
The following sections describe each extension point, the actions, and the data items that are appropriate for each one.
For all the extension points you can read the extension-point and set trace-level in the environment dictionary. For most extension points you can also tell the server to drop the packet.
The following data items are available to all extension points:
For all extension points that have a request dictionary, the data items that begin with log and verbose-logging can be set at any time. The DHCP server reads them as needed.
Dictionaries available: request, environment
This is one of the easiest extension points to use, and if you can express the change in server behavior as a rewrite of the input DHCP or BOOTP packet, you should use this extension point. Because the packet has been decoded, but not processed in any way, the number of side effects that you have to be aware of are very limited.
This is the only extension point at which you can make modifications to the decoded input packet and be sure that all the modifications will be recognized.
If the extension decides that the packet should be dropped, and further processing terminated, it may do so by using the drop data item in the environment dictionary.
All of the decoded packet data items are specified in the "DHCP Extension Dictionary Entries" appendix.
Table 4-2 lists items that are available in the post-packet decode request dictionary.
| Item | Value | Operation |
|---|---|---|
int | r/w | |
IP address | r/w | |
int | r/o |
Dictionaries available: environment, request
You can only use the pre-client-lookup extension point if you have enabled client-class processing for your DHCP server.
This extension point allows an extension to perform any or all of the following actions:
Although the request dictionary is available in order to make decisions regarding the operation of an extension running at this extension point, all of the operations are controlled through the environment dictionary.
The following items are available at pre-client-lookup for client-class control:
If you set the following data items, their values will override the values determined from the client lookup (either in the internal database or from LDAP). If you set them to a null string, then that is what the DHCP server will use.
You can use all of the decoded packet data items specified in the "DHCP Extension Dictionary Entries" appendix.
Table 4-3 describes request information items that are available in the pre-client-lookup request dictionary.
| Data Items | Value | Operation |
|---|---|---|
Client-port | int | r/w |
Client-ipaddress | IP address | r/w |
Transaction-time | int | r/o |
Table 4-4 describes client information items that are available in the pre-client-lookup request dictionary.
| Data Items | Value | Operation |
|---|---|---|
Client-id | blob | r/w |
Client-id-created-from-mac-address | int | r/o |
blob | r/w | |
Client-mac-address | blob | r/w |
Table 4-5 describes client understanding items that are available in the pre-client-lookup request dictionary.
| Data Items | Value | Operation |
|---|---|---|
Client-wants-nulls-in-string | int | r/w |
int | r/w | |
int | r/w |
Dictionaries available: environment and request
You also can use this extension point to place some data items in the environment dictionary in order to affect the processing of some extension running at the pre-packet-encode extension point (where it might load different options into the response packet or take other actions).
The following data item is available at post-client-lookup:
You can use all the decoded packet data item described in the "DHCP Extension Dictionary Entries" appendix.
Table 4-6 describes request information items that are available in the post-client-lookup request dictionary.
| Data Items | Value | Operation |
|---|---|---|
Client-port | int | r/w |
Client-ipaddress | IP address | r/w |
int | r/o |
Table 4-7 describes client information items that are available in the post-client-lookup request dictionary.
| Data Items | Value | Operation |
|---|---|---|
Client-id | blob | r/w |
Client-id-created-from-mac-address | int | r/o |
blob | r/w | |
Client-mac-address | blob | r/w |
Table 4-8 describes client understanding information items that are available in the post-client-lookup request dictionary.
| Data Items | Value | Operation |
|---|---|---|
Client-wants-nulls-in-string | int | r/w |
int | r/w | |
int | r/w | |
Client-policy | string | r/w |
Client-class-policy | string | r/w |
Client-host-name | string | r/w |
Client-domain-name | string | r/w |
Client-requested-host-name | string | r/w |
Client-class-name | string | r/o |
string | r/w | |
string | r/w |
Dictionaries available: request, response, environment
This check-lease-acceptable extension point comes immediately after the server has determined whether the current lease is acceptable for this client. You can use this extension to examine the results of that operation, and to cause the routine to return different results. For important information about using this extension point, see the "Determine if This Lease Is Acceptable" section earlier in this chapter.
The following data item is available in the environment dictionary at the check-acceptable extension point:
All data items available for pre-packet-encode are available for check-lease-acceptable.
All data items available for pre-packet-encode are available for check-lease-acceptable response.
Dictionaries available: request, response, and environment
You can use all the decoded packet data items described in the "DHCP Extension Dictionary Entries" appendix.
Table 4-9 describes request information items that are available in the pre-packet-encode request dictionary.
| Data Items | Value | Operation |
|---|---|---|
int | r/w | |
IP address | r/w | |
int | r/o |
Table 4-10 describes client information items that are available in the pre-packet-encode request dictionary.
| Data Items | Value | Operation |
|---|---|---|
blob | r/w | |
int | r/o | |
blob | r/w | |
blob | r/w |
Table 4-11 describes client understanding information items that are available in the pre-packet-encode request dictionary.
| Data Items | Value | Operation |
|---|---|---|
int | r/w | |
int | r/w | |
int | r/w | |
string | r/w | |
string | r/w | |
string | r/w | |
string | r/w | |
string | r/w | |
string | r/o | |
string | r/w | |
string | r/w |
You can use all the decoded packet data item described in the "DHCP Extension Dictionary Entries" appendix.
Table 4-12 describes data items in the available in the pre-packet encode response dictionary.
| Data Items | Value | Operation |
|---|---|---|
IP address | r/w | |
int | r/w | |
int | r/o | |
int | r/o | |
int | r/o | |
string | r/o | |
int | r/o | |
int | r/o |
Table 4-13 describes client information items that are available in the pre-packet-encode response dictionary.
| Data Items | Value | Operation |
|---|---|---|
string | r/w | |
string | r/w | |
blob | r/w | |
int | r/o | |
blob | r/w | |
string | r/w | |
int | r/w | |
int | r/w | |
int | r/w | |
int | r/o | |
blob | r/w | |
int | r/w |
Table 4-14 describes lease information items that are available in the pre-packet-encode response dictionary.
| Data Items | Value | Operation |
|---|---|---|
int | r/o | |
IP address | r/o | |
int | r/o | |
string | r/o | |
int | r/o |
Table 4-15 describes scope address information items that are available in the pre-packet-encode response dictionary.
| Data Items | Value | Operation |
|---|---|---|
IP address | r/o | |
IP address | r/o | |
IP address | r/o | |
IP address | r/o |
Table 4-16 describes scope acceptability information items that are available in the pre-packet-encode response dictionary.
| Data Items | Value | Operation |
|---|---|---|
int | r/o | |
int | r/o | |
int | r/o | |
int | r/o | |
int | r/o |
Table 4-17 describes scope DNS information items that are available in the pre-packet-encode response dictionary.
| Data Items | Value | Operation |
|---|---|---|
IP address | r/o | |
string | r/o | |
int | r/o | |
IP address | r/o | |
string | r/o | |
int | r/o | |
int | r/o |
Dictionaries available: environment
You can use the pre-dns-add-forward extension point to choose the name and affect the DNS retries during update operations.
Posted: Thu Jul 13 11:15:42 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.