This page contains instructions for creating and managing MAC address filters for DHCP.

Introduction

A MAC Address Filter is a Grid Manager object which keeps track of a set of MAC addresses.

MAC Address Filters are typically used to restrict access to IPv4 DHCP Ranges. Once you have configured your MAC Address Filter the way you want it using the instructions below, see Restricting Access to a Range to apply it to a DHCP Range.

Creating a new MAC Address Filter

If you need a new MAC Address Filter, please email hostmgr to request one. Provide the following details:

• a desired name for the new MAC Address Filter object.

  There is a single global namespace for all Filters, so try to choose something reasonable that incorporates the department or group for which this filter is relevant. If in doubt, explain what you plan to use it for, and we will help you choose a suitable name.

• the name(s) of one or more network models (from Contacts Database) that should confer “ownership” rights to this MAC Address Filter. Any user with permissions on any of the named network models will automatically be given permission to manage this MAC Address Filter as well (updated nightly).

  These network model names will be stored in Grid Manager as values of an Extensible Attribute called “Owned By Network”. Modifying or removing this attribute may result in loss of permissions on the MAC Address Filter.

Managing MAC addresses in a MAC Address Filter

To open a MAC Address Filter:

1. Navigate to Data Management > DHCP > Filters using the rows of tabs at the top of the screen.
2. Open the desired MAC Address Filter by clicking on its name in the table.

This will display a table containing all MAC addresses currently present in the MAC Address Filter.

If your table contains many rows, see Using the Table Controls in Getting Started with IPAM.

Adding a MAC address

After opening a MAC Address Filter as described above,

1. Click the Add (+) icon above the table.
2. Enter the desired MAC address.
3. Optionally, you may set an expiration time at which this MAC address will be automatically removed from the MAC Address Filter.
4. Click “Next” at the bottom of the dialog window.

5. Optionally, you may enter a username in the “Register as User” field to associate with this MAC address (for your own tracking purposes).  If you don’t want to do this, just leave it blank.

6. Click “Save & Close”.

Removing a MAC address

After opening a MAC Address Filter as described above,

1. Select the checkbox for the MAC address you wish to remove (making sure no other checkboxes are selected).
2. Click the Delete (trash can) icon above the table.
3. If you’re sure, click “Yes” when the confirmation dialog appears.

go.illinois.edu/ipamtraining (this page)

1. Open https://dev.ipam.illinois.edu
2. Double-check that the login screen says “DEVELOPMENT GRID”!
3. Click “SSO Login” or see go.illinois.edu/ipamlogin for detailed login instructions
   (If you don’t have any Contacts Database permissions, contact hostmgr to request demo access to dev.ipam)
4. Follow along with the live training instructions or the self-guided tutorial in Getting Started with IPAM

Dummy Objects

Dummy objects (in development grid only) that everybody has permissions on, for training purposes:

• sandbox.illinois.edu
• 192.168.0.0/26 (sandbox-net)
• 2001:db8::/64 (sandbox-net)
• sandbox-macfilter

Sample dig commands

• dig @dev.ipam.illinois.edu hostname.sandbox.illinois.edu IN A
  (variations: “IN AAAA”, “IN CNAME”, “IN any”, etc)
• dig @dev.ipam.illinois.edu -x 192.168.0.5

IPAM Service Documentation

The service documentation at go.illinois.edu/ipam contains step by step instructions for common tasks.

Lease Time Guidelines

The default DHCP lease time is 1 day, which is well suited for nets with low turnover (i.e. the population of client machines is fairly stable and doesn’t change much).

Network administrators may choose to configure a different lease time on individual IPv4 DHCP Ranges (Dynamic Pools), subject to the following guidelines which are designed to keep overall load on the DHCP servers from growing unsustainably:

Because IPv6 subnets are so spacious, there is generally no reason to reduce the DHCPv6 lease time parameters; IPv6 nets with higher host turnover which require Stateful autoconfiguration can simply be configured with larger DHCP Ranges in order to avoid running out of leases.

Range Size Guidelines

IPv4 DHCP Ranges (Dynamic Pools) should be sized so that the number of unassigned IP addresses in the Range (after all desired clients have obtained their leases, and not counting any addresses within Exclusion Ranges) will be at least 1-5% of the total, with a minimum of at least 2 unassigned IP addresses (even for very small Ranges) in order to properly utilize the redundancy provided by DHCP Failover.

Note: Email Alert thresholds should also be adjusted accordingly (to higher than 95%) if the expected number of unassigned IP addresses is less than 5% of the total.

Service Defaults

The following DHCP settings serve as defaults; they are configured at the top level of the Grid hierarchy and automatically inherited by all Networks. An individual Network, DHCP Range, DHCP Fixed Address, or DHCP-enabled Host can override one of these defaults by specifying its own value for the setting.

Client options

For DHCPv4:

For DHCPv6:

Service settings

For DHCPv4:

• Lease Time: 1 day (see Lease Time Guidelines above)
• Authoritative: true

• Ping Check: 1 request, with 1 second timeout

  This setting cannot be overridden for individual Networks or Ranges.

• Enable DDNS Updates: false

  ddns-updates false prevents the DHCP server from attempting to do dynamic DNS updates on behalf of clients that choose to send a Client FQDN value in their DHCPREQUEST. This setting is not one of the options transmitted to clients, and will not affect their ability to perform their own dynamic DNS updates in Active Directory (or any other DDNS server).

For DHCPv6:

• Valid Lifetime: 2 days

• Preferred Lifetime: 1 day

• Enable DDNS Updates: false

Requesting Autoconfiguration Service

To enable autoconfiguration for your existing network, email net-trouble@illinois.edu with the following information:

• The name and IP CIDR of the network
• Which type of autoconfiguration you would like to enable (see below for details)
• If the network already has a DHCP server, let us know and provide details so that we can assist you in migrating your existing DHCP configuration into IPAM.
• Optionally, any other special configuration changes you require at this time (e.g. DHCP options set at the network level)

For new networks, work with your network designer to request autoconfiguration service as part of the network creation process.

Autoconfiguration Design Guide

There is no one-size-fits-all optimal approach to autoconfiguration; which type you choose, and which DHCP objects you configure in IPAM, will vary depending on how you want to use and administer your network.

The first step is to determine which of the following client behaviors you want to support:

• dynamic address allocation: each client automatically obtains an available IP address which is arbitrary and unpredictable. It doesn’t matter which client gets which IP, or if a particular client gets a different IP next time it comes back. This behavior is the easiest to configure, and requires very little administrative maintenance once set up.
• fixed address allocation: each client automatically obtains an IP address which has been administratively reserved for that client’s exclusive use.  This behavior requires more configuration work in IPAM (new clients must be added and old ones removed), but allows individual client IPs to be stable and predictable.
• manual client configuration: each client device is manually configured with the necessary network parameters, and does not use autoconfiguration at all. This is usually only necessary for devices which do not support autoconfiguration.

It is possible to mix and match, using different behaviors for different clients on the same network, but care must be taken to avoid conflicts!

Next, select the autoconfiguration type that best supports your desired behavior(s) – these are covered in detail in the following sections – and request that type of autoconfiguration service on your network.

Finally, if you’ve chosen DHCPv4 and/or IPv6 Stateful autoconfiguration, configure the desired DHCP objects in IPAM (see Using IPAM for detailed instructions):

• DHCP Ranges (Dynamic Pools) for dynamic address allocation

• DHCP-enabled Host Records and/or DHCP Fixed Addresses for fixed address allocation

  Notes for Microsoft DHCP users

  A Microsoft DHCP “Reservation” corresponds to a “Fixed Address” in IPAM. Avoid the temptation to create a “Reservation” in IPAM; that term refers to a different concept entirely and will not accomplish what you intend.

  Also, there is no need to place Fixed Addresses inside a DHCP Range (a “scope” in Microsoft terms); in fact, it’s best practice to avoid doing this. If you don’t want to use dynamic address allocation behavior on your network, you should not create a DHCP Range at all.

IPv4 Autoconfiguration Types

For IPv4, autoconfiguration is synonymous with DHCPv4, so the standard choices are simple; DHCPv4 is either enabled or disabled for any given network.

Notes:

• Several best practice recommendations are discussed in DHCP Ranges (Dynamic Pools).
• One strategy for preserving flexibility on a mixed-behavior net is to create a DHCP Range near the end of the net (i.e. highest-numbered IPs), and allocate Fixed Addresses, DHCP-enabled Hosts, and static IPs for manual configuration (if any) starting from the beginning of the net (lowest-numbered IPs).

IPv6 Autoconfiguration Types

For IPv6, there are multiple standard implementation choices for autoconfiguration, each supporting different behavior(s):

Notes:

• Where feasible, choose Stateless over Stateful autoconfiguration for your IPv6 networks.
  • Stateless is simpler than Stateful, and significantly easier on the DHCP servers.
  • If your network includes clients without DHCPv6 support, they will still be able to obtain an IPv6 address using Stateless autoconfiguration. Such clients will not learn the IPv6 DNS resolver address or other option values, but in many cases clients can function successfully without this information (e.g. by using IPv4 for DNS resolution, if available).
  • It is easy to migrate between Stateless and Stateful in the future if your requirements change.
• Most modern clients do support DHCPv6, as shown in https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems.

Limitations of DHCPv6 fixed address allocation

The DHCPv4 protocol specification (RFC 2131) includes a “client hardware address” (chaddr) field which in practice contains the MAC address of the requesting client’s network interface.  This makes it easy for a DHCPv4 server to identify clients by MAC, and to assign fixed address allocations based on the client’s MAC.

The DHCPv6 protocol specification (RFC 3315) does not include a client hardware address field; instead, it defines the DHCP Unique Identifier (DUID) which is intended as an opaque, globally unique, and stable identifier for the whole client device (not just for one of its network interfaces).  Because the MAC address is not included in DHCPv6 messages, there is currently no way for a DHCPv6 server to assign fixed address allocations based on the client’s MAC address; instead, you must configure them based on the client’s DUID.

The challenge is that it can be difficult or impossible to learn the client’s DUID ahead of time.  While the MAC address is a property of the physical hardware, the DUID (for most general-purpose computers, at least) is a software property generated and stored on disk by the operating system.  Depending on your operating system, the DUID may not even exist until it is needed for the first time – and it will almost certainly change if you reinstall the operating system, dual-boot to a second operating system, etc.

Recommendations:

• Where possible, sidestep this issue entirely by using dynamic address allocation instead of fixed.
• If you do require fixed address allocation, make sure you understand the challenges discussed in this section and that you have a strategy for ascertaining client DUIDs.

Other Information

DHCP Standards details important guidelines and recommendations for using the DHCP service, as well as the default configuration parameters that will automatically apply to all networks unless you choose to override them.

Email Alerts explains the automated email notifications that may be sent to network administrators by the DHCP service.

This page contains information about other DNS and DHCP tools available to campus IT professionals.

Production IPAM

Production IPAM Grid Manager is located at https://ipam.illinois.edu/

See Using IPAM for instructions.

Development IPAM

The development IPAM system located at https://dev.ipam.illinois.edu/ is a good place to safely experiment with new CSV imports, API scripts, or interface features you haven’t used before. Please note that we enable IT Pros to use dev.ipam on an “as is” basis, with the important caveats that it is not always available, often contains data that is inaccurate or extremely out of date, and may be completely overwritten at any time without warning.

dev.ipam is not reachable from off-campus, so you may need to use the VPN.

Test authoritative DNS queries sent to dns-dev1.techservices.illinois.edu (from on campus) will be answered using the data configured in dev.ipam:

dig +norecurse @dns-dev1.techservices.illinois.edu foo.sandbox.illinois.edu a

dhcpmon

dhcpmon provides graphs for each subnet showing the utilization of dynamically-allocated DHCP addresses over the past day, week, month, and year.

Please note the following limitations:

• actual usage data may be up to 15 minutes older than the graph timestamp
• abandoned lease counts are updated only once per day
• addresses from multiple Ranges are aggregated together
• unused addresses within Reserved Ranges are misleadingly counted as available even though in fact they can never be assigned to a DHCP client (see also Known Issues)

In general, dhcpmon works well for the common case of nets containing a single DHCP Range (with optional Exclusion Ranges).  If your net contains multiple DHCP Ranges and/or any Reserved Ranges, be very careful when drawing conclusions from dhcpmon data.

Domain Request Form

The Domain Request Form is located at go.illinois.edu/domainrequest

See Requesting DNS Domains for more information.

Contacts Database

Network administrators can now keep their identities up to date using Contacts Database.

dig

dig is the preferred client tool for troubleshooting DNS issues because of its flexibility and detailed output. This section is intended as a quick-start guide to help you get it running on your workstation.

See also https://help.dyn.com/how-to-use-binds-dig-tool/

Windows:

1. Browse to https://downloads.isc.org/isc/bind9/cur/9.16/ and download the latest stable release of BIND 9 as a Windows zip file (e.g. “BIND9.16.7.x64.zip“).
2. Extract the zipfile’s contents to a temporary directory on your workstation.
3. Run “BINDInstall.exe” and choose the “Tools only” option (since you don’t want to install the BIND server on your workstation).

4. Open a Command Prompt and run dig from the directory where you installed it, e.g.

   cd "C:\Program Files\ISC BIND 9\bin"
   dig

   Note that previous versions installed dig under C:\WINDOWS\system32\dns\bin or C:\WINDOWS\SysWOW64\dns\bin

5. Optionally, you may add the above bin directory to your PATH for convenience (the details of this step are outside the scope of this document, but try searching the web for “set windows path”).

Mac OS X:

• Modern versions of OS X come with dig pre-installed. Just open a Terminal window and run dig.

Linux:

• dig is readily available as a package for most linux distributions. Look for a package called “bind-utils”, “dnsutils”, or “dnstools”.

To test that your installation of dig is working, run a simple query:

dig @8.8.8.8 www.illinois.edu a

This should return the IP address of our web server (in the ANSWER section).

Plenty of other documentation has already been written about the details of working with dig; just search the web for “dig tutorial”.
See also the dig manual page.

Host Manager

If you have questions about campus DNS services, email hostmgr@illinois.edu.