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.

This page summarizes known issues with IPAM Grid Manager that may be relevant to campus network administrators.

Authentication

• Even though they both ultimately derive from the same Active Directory user object, Grid Manager regards `yournetid` (the SAML identity that you use for SSO Login) and `yournetid@illinois.edu` (the userPrincipalName identity that you use for API access and the optional Alternative Login Method) as two separate users who happen to have the same permissions.
  This has the following practical consequences:

  • Each user profile has its own independent set of GUI personalizations, so e.g. Smart Folders or table customizations you create for your SSO Login identity will not be visible when you log in with your userPrincipalName identity (nor vice versa).  This can be a confusing user experience, especially if you frequently switch back and forth, so our general recommendation for most people is to always access the GUI using “SSO Login”.

  • User profile settings, Smart Folders, Scheduled Tasks, etc that belong to your SSO Login identity cannot be managed using the API.
  • Here is a partial (not exhaustive) list of user profile customizations you may wish to consider manually recreating when you switch login methods:
    • (your username in upper-right corner) > Profile: Table Size
    • Finder > Smart Folders
    • Finder > Bookmarks
    • column customizations for various tables (e.g. adding “Network Name” to both Data Management > IPAM and Data Management > DHCP > Networks > Networks)
    • saved Quick Filters for various tables
    • “Toggle Advanced Mode” in various dialog boxes
    • “Toggle flat view” in Data Management > DNS > Zones > Records
    • “Include Extensible Attributes Values” in Search > Advanced

Discovered Data

• Please avoid using the “Ping” (and “Multi-Ping”) toolbar buttons within IPAM.  Successful pings have the side effect of storing “Discovered Data” for the IP which unfortunately cannot be cleared using normal permissions; it must be cleared by hostmgr (or a nightly automated script) on your behalf.  This Discovered Data can inconvenience you in several ways, including manifesting visually in IPAM as a purported “conflict” or “unmanaged” address, and/or preventing you from creating a Range.

Leases

• In IPAM view (Viewing Leases in a Network), “Static” Leases from Fixed Addresses or DHCP-enabled Hosts are only displayed if the IP in question happens to fall within a DHCP Range.
• Depending on your individual network permissions, some users may experience a significant delay and eventual timeout when clicking on the Current Leases tab.  The text of the error message is:
  “The system is taking longer than expected to complete your request. The system will continue to process any changes you made in the background. Please wait, then check whether your changes were applied. If you did a search, please refine your query and retry your request.”
  Workarounds:
  • wait for it to time out, then apply a Filter (e.g. “IP Address” “begins with” …) to limit the scope of the query
  • use one of the other two methods described in Managing DHCP Leases instead
• Grid Manager does not appropriately account for Abandoned Leases when calculating the DHCP utilization statistics (per Range and per Network) which are shown in Grid Manager, returned by the API, tracked by dhcpmon, and used to trigger DHCP Threshold Email Alerts.  For example, a Range which contains 90% Active Leases and 10% Abandoned Leases will not generate an alert because Grid Manager considers it to be only 90% utilized, even though live clients may be unable to obtain a lease (depending on how many of the Abandoned Leases are actually still in use on the network).
  Workarounds:
  • dhcpmon has been enhanced to display the most recent Abandoned lease count per network (data updated once per day)
  • hostmgr now receives automated notifications regarding networks which are over 95% full including Abandoned leases, so we can manually reach out to CDB network contacts to let them know when this problem has become serious
• Addresses within Reserved Ranges are counted (along with DHCP Ranges) in the per-Network DHCP Utilization statistics shown in Grid Manager, returned by the API, and tracked by dhcpmon.  Consequently, the presence of Reserved Ranges may cause a network to appear less full than it actually is.  This does not affect Email Alerts (which apply individually to each Range).
  • Workaround: Edit the Reserved Range and check “Disable for DHCP”.

Search

• Basic Search for DNS Name does not currently find Host Aliases.
• Advanced Search for an IPv6 address will only succeed if you enter the exact string representation of the address that Grid Manager uses internally.  For example, you will not find “2620:0:e00:b::53” by searching for “2620:0000:0e00:000b::53” (extra leading zeros) or “2620:0:e00:b:0:0:0:53” (no double colon abbreviation), even though these are all valid representations of the same IPv6 address.
  • Workaround: use Basic Search by IP Address instead.

DNS Traffic Control

• DNS Traffic Control may return your fallback records (instead of synthesized responses) for about 1 second after a restart of services in which other DTC configuration changes are being applied, even if those changes have nothing to do with your LBDN.  Mitigation: choose good fallback records.
• Grid Manager currently displays fallback records in normal font instead of strikethrough font

Misc

• Due to shared implementation logic under the hood, if you try to create a Fixed Address with MAC address “00:00:00:00:00:00”, IPAM will silently create a “Reservation” object instead.  This is especially confusing because there is no way to convert a “Reservation” back into a Fixed Address later; it must be deleted.
  • Workaround: if you need a dummy placeholder MAC address, consider using one that begins with “02:”

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

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.