DHCP Expressions

Overview

Cisco Prime Network Registrar provides enhanced client-class support. You can now place a request into a client-class based on the contents of the request, without having to register the client in the client database. Also, you can now place requests in a client-class based on the number of the active leases of a subscriber, allowing limitations on the level of service offered to various subscribers. This is possible through the special DHCP options processing using expressions.

Most expressions that are configured with the CLI are stored in a text file which is then associated with the desired configuration attribute. The default path of this file is the current working directory. You can configure a simple expression directly in the CLI without storing it in a text file. Simple expressions must adhere to these rules when you enter them in the CLI:

  • They must be limited to a single command line.
  • The entire expression must be enclosed in double quotes (" ").
  • Embedded double quotes must be escaped with a backslash (\).

Usage

There are basically four fields with the DHCP server configuration where expressions can be entered. These expressions can provide the following uses by interpreting the incoming packet data to produce a value which than can be used for making decisions within the server for processing that packet.

  • Determining a client-class
  • Determining a client identifier for client look up
  • Determining a subscriber identifier for assigning client devices to a pool which can be then counted
  • Providing a client identifier which can override the client-id provided by the contents of the packet which may be used for DNS purposes.

Examples

(if (starts-with (request get chaddr) “01:02:03”) “VoIP” “PC”)

What this expression does is determine if the first three octets of the client’s MAC address reflect that the manufacturer of the device is a specific VoIP equipment manufacturer and thus represents that the device belongs in the VOIP client class. If the MAC address is something else, it is a PC and gets assigned the PC client class. Since all DHCP DISCOVERs have a chaddr, the try function is not necessary.

Similar to LISP – lots of parentheses – everything is a function

  • (request option 82 remote-id) - returns the remote-id or null if no option 82 is present – null is bad
  • (try (request option 82 remote-id) “no option 82”) – returns the remote-id or the string if

Call Flow

Limitation-id counting limited to a single lan-segment

Use the following config:

Create client-classes and clients as follows:

Scope-selection-tag tag1

policy two create
policy two set limitation-count=2

client-class class1 create policy-name=two
client-class class1 set selection-criteria=tag1

client-class class2 create policy-name=two

client 1,6,01:02:03:04:05:01 create client-class-name=class1
client 1,6,01:02:03:04:05:02 create client-class-name=class1
client 1,6,01:02:03:04:05:03 create client-class-name=class1
client 1,6,01:02:03:04:05:04 create client-class-name=class2

dhcp enable client-class

scope scope1 create 1.1.1.0 255.255.255.0
scope scope1 addrange 1 10
scope scope1 set selection-tags=tag1

scope scope2 create 2.2.2.0 255.255.255.0
scope scope2 addrange 20 40

Both class1 and class2 have the same limitation-id expression, which is:

(substring (request chaddr) 0 2)

  • No expression is configured for client-class-lookup-id.
  • Client 01 and 02 come in; both have giaddr=1.1.1.0. Verify both should get leases from scope1. Run the lease show command. Verify the limitation-id values.
  • Client 03 comes in with giaddr=1.1.1.0. Verify the request gets dropped as it exceeds limitation-count quota.
  • Client 04 comes in with different giaddr=2.2.2.0. Verify it gets lease from scope2. Run the leases show command. Verify the value of the limitation-id.
  • Now make scope2 be secondary to scope1. Repeat. Client 04 should now be rejected as it exceeds the limitation-count.