
Interfaces and Subnets
40
Tip
If you are setting up a static allocation, but your client has already obtained an address (from your
FB2700) from a pool, you will need to clear the existing allocation and then force the client to issue
a new DHCP request (e.g. unplug the ethernet cable, do a software 'repair connection' procedure or
similar). See the
show dhcp
and
clear dhcp
CLI commands in Appendix I for details on how
to clear the allocation. Chapter 21 covers the CLI in general.
You can also lock an existing dynamic allocation to prevent it being re-used for a different MAC address even
if it has expired.
6.3.2.2. Restricted allocations
You can restrict a pool to apply only to devices with specific MAC addresses, client names or vendor class
names using the
mac
,
client-name
and
class
attributes on the
dhcp
object. The client and class names
can be specified using wildcard strings, where the characters '*' and '?' stand for any run of characters, and any
single character, respectively. The value specified for the
mac
attribute can be a list of partial MAC addresses,
where each item can be less than a full 6-byte address. Any device whose MAC's leading bytes match one of
the items in the
mac
list is acceptable. [The fixed-allocation example above is actually a special case of this
general method for restricting allocation pools, where a single MAC address was specified in full.]
For example, as discussed in Appendix C, the first three octets (bytes) of a MAC address identify the
organization (often the end product manufacturer) which is registered to allocate that MAC address to an
Ethernet device. By specifying only these first three bytes (six hexadecimal characters, no colon delimiters), in
the
mac
attribute, you can ensure that all devices from the associated manufacturer are allocated addresses from
a particular address pool. This is helpful if you have some common firewalling requirements for such a group
of devices - for example, if all of your VoIP phones are from one manufacturer, as you can have appropriate
firewall rule(s) that apply to addresses in that pool.
The following example illustrates this technique. It will match any devices which have MAC addresses
beginning 00:04:13 or 00:0E:08, and which also have a vendor class name containing the string phone:
<interface ...>
...
<dhcp name="VoIP"
ip="10.20.30.40-50"
mac="000413 000E08"
class="*phone*"
dns="8.8.8.8"
log="DHCP-Phones"
comment="VoIP phones"/>
...
</interface>
The algorithm used to determine which pools apply to a particular device is as follows:
• If no restricted pools (ie those with one or more of the
mac
,
client-name
or
class
attributes present)
match the device's properties, then all non-restricted pools apply.
• If any restricted pools match the device's properties, then only restriced pools which match the device apply.
Furthermore, a scoring system is used to select which of those pools to use based on how well the device's
properties match. An exact match scores higher than any partial or wildcarded match and a MAC match
scores higher than a client-name match, with a class-name match scoring the least. The score for a partial or
wildcarded match is based on the number of bytes or characters which were explicitly matched.
• Only the pool or pools with the highest score are considered.