You can alter and customize the operation of the Cisco Prime Network Registrar DHCP server by using extensions, functions that you can write in Tcl or C/C++.
Follow this process to create an extension for use in the DHCP server:
- Determine the task to perform. What DHCP packet process do I want to modify?
- Determine the approach to use. How do I want to modify the packet process?
- Determine the extension point to which to attach the extension.
- Choose the language (Tcl or C/C++).
- Write (and possibly compile and link) the extension.
- Add the extension to the DHCP server configuration.
- Attach the extension to the extension point.
- Reload the DHCP server so that it recognizes the extension.
- Test and debug the results.
While upgrading Cisco Prime Network Registrar, it is recommended to recompile all the DHCP C/C++ extensions (dex extensions).
Creating, Editing, and Attaching Extensions
You can create, edit, and attach extensions.
You can associate multiple extensions per extension point. Each extension executes in the order specified by the sequence number used when the attachment was created. In the web UI, the sequence is the order in which the extensions appear per extension point on the List DHCP Extension Points page. In the CLI, you use the sequence-number value with the dhcp attachExtension command.
For more on multiple extensions per extension point, see Multiple Extension Considerations.
Local Advanced Web UI
Creating and Attaching Extensions
From the Deploy menu, choose Extensions under the DHCP submenu to open the List/Add DHCP Extensions page.
Click the Add Extensions icon to open the Add DHCP Server Extension dialog box.
After you create an extension, you can attach it to one or more of the extension points on this page. To show the extension points where you can attach extensions, on the List/Add DHCP Extensions page, click DHCP Extension Points tab .
If you attach more than one extension for each extension point, you can change the sequence in which they are processed by clicking the arrow keys to rearrange the entries. To remove the extension, click the Delete icon.
Use the extension command, which requires this syntax:
nrcmd> extension name create language extension-file entry-point
The entry-point is the name of the entry point in the extension-file. You can also set an optional init-entry attribute value for the initial entry point each time the DHCP server loads the file (see init-entry). You can call this function from any extension point bound to this module. You can also list the extensions using extension list .
To attach and detach an extension, use dhcp attachExtension and dhcp detachExtension for the DHCP server, which require this syntax:
nrcmd> dhcp attachExtension extension-point extension-name [sequence-number] nrcmd> dhcp detachExtension extension-point [sequence-number]
The sequence-number applies if you attach multiple extensions per extension point, in increasing sequence order ranging from 1 through 32. If omitted, it defaults to 1.
To view the currently registered extensions, use dhcp listExtensions command.
The task to which to apply an extension is usually some modification of the DHCP server processing so that it better meets the needs of your environment. You can apply an extension at each of these DHCP server processing points, from receiving a request to responding to the client:
- Receive and decode the packet.
- Look up, modify, and process any client-class.
- Build a response type.
- Determine the subnet (or link, in the case of DHCPv6).
- Find any existing leases.
- Serialize the lease requests.
- Determine the lease acceptability for the client.
- Gather and encode the response packet.
- Update stable storage of the packet.
- Return the packet.
A more complete list of these steps (along with the extension points to use at each step) appears in DHCP Request Processing Using Extensions.
For example, you might have an unusual routing hub that uses BOOTP configuration. This device issues a BOOTP request with an Ethernet hardware type (1) and MAC address in the chaddr field. It then sends out another BOOTP request with the same MAC address, but with a hardware type of Token Ring (6). Specifying two different hardware types causes the DHCP server to allocate two IP addresses to the device. The DHCP server normally distinguishes between a MAC address with hardware type 1 and one with type 6, and considers them 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.
Deciding on Approaches
Many solutions are often available to a single problem. When choosing the type of extension to write, you should first consider rewriting the input DHCP packet. This is a good approach, because it avoids having to know the internal processing of the DHCP server.
For the problem described in Determining Tasks, you can write an extension to solve it in either of these ways:
- Drop the Token Ring (6) hardware type packet.
- Change the packet to an Ethernet packet and then switch it back again on exit.
Although the second way involves a more complex extension, the DHCP client could thereby use either reply from the DHCP server. The second approach involves rewriting the packet, in this case using the post-packet-encode extension point (see post-packet-encode). Other approaches require other extensions and extension points.
Choosing Extension Languages
You can write extensions in Tcl or C/C++. The capabilities of each language, so far as the DHCP server is concerned, are similar, although the application programming interface (API) is slightly different to support the two very different approaches to language design:
- Tcl —Although scripting in Tcl might be somewhat easier than scripting in C/C++, it is interpreted and single-threaded, and might require more resources. However, you might be less likely than in C/C++ to introduce a serious bug, and there are fewer chances of a server failure. Cisco Prime Network Registrar currently supports Tcl version 8.4.
- C/C++ —This language provides the maximum possible performance and flexibility, including communicating with external processes. However, the C/C++ API is more complex than the Tcl API. Also, the possibility of a bug in the extension causing a server failure is also more likely in C/C++.