DHCP Ranges (Dynamic Pools)

This page contains information about configuring DHCP Ranges (Dynamic Pools) and DHCP options.

Introduction

A DHCP Range provides a pool of IP addresses that can be assigned interchangeably to any eligible DHCP client.

To configure an individual IP address for use exclusively by a single DHCP client, see DHCP Fixed Addresses or Adding DHCP to a Host Record.

The instructions below assume that you are working in DHCP View (see Getting Started with IPAM). Some DHCP configuration tasks can also be performed from IPAM View, but the exact sequence of steps may differ.

Creating A New IPv4 DHCP Range

To create a new DHCP Range:

  1. Open the Network in which you want to add a new range (see Getting Started with IPAM).
  2. Click the dropdown arrow next to the Add (+) icon above the table in the main workspace, then choose “Range”.
  3. Click “Next” at the bottom of the dialog window.
  4. Enter the desired Start (first) and End (last) IP addresses for the range.

    Make sure the range will be large enough to comply with Range Size Guidelines.

  5. Optionally enter an internal display name and/or a comment.
  6. Click “Next”.

  7. Important: for “Served by”, choose “IPv4 DHCP Failover Association” and then click the “Select Association” button to automatically select “DHCP-A” which is the only failover association available.

    Do NOT select “Grid Member”.  Although a DHCP Range served by a single Grid Member may appear at first glance to function correctly, this configuration is unsupported because it does not properly utilize the redundancy provided by DHCP Failover.

  8. Click “Save & Close” at the bottom of the dialog window.

Editing a Range

To edit an existing Range:

  1. Navigate to the Range you want to edit (e.g. by opening its Network in DHCP View, see Getting Started with IPAM).
  2. Select the checkbox for the Range object and click the Edit (notepad) icon above the table.  This opens the Edit dialog box.
  3. Be sure to enable Advanced Mode for the dialog.
  4. Make any desired changes (see subsections below).
  5. Click “Save & Close”.

Setting DHCP Options

See DHCP Standards for the option values that will automatically apply unless you choose to override them.

To configure additional DHCP options:

  1. Choose the “IPv4 DHCP Options” subscreen in the Edit dialog.
  2. Scroll down to the “Custom DHCP Options” section at the bottom.
  3. Add your new option in the last row:
    1. First field:
      • Choose a custom vendor option space if you wish to set a vendor-specific option which will be automatically encapsulated inside option 43 (see RFC 2132 Section 8.4) when replying to clients with the appropriate vendor class identifier (option 60).
      • Otherwise, choose “DHCP” to set a standard DHCP option.
    2. Second field: choose which option to set.  Option names are not standardized and may vary by implementation, so check the numeric option code (displayed in parentheses) to be sure you have the right one.

      If you need to set a custom DHCP option or vendor-specific option that is not yet defined in Grid Manager (i.e. does not appear in the drop-down lists), please contact hostmgr@illinois.edu.
    3. Third field: type the desired value.  The format of this value depends on the type defined for the option; see DHCP Option Data Types in the vendor documentation.
  4. To add another option, click the + button.

To configure BOOTP/PXE settings:

  1. Choose the “IPv4 BOOTP/PXE” subscreen in the Edit dialog (requires Advanced Mode).
    Click the Override button next to the setting you wish to override, and enter a new value.

    Hint: most PXE clients require values for Next Server and Boot File (which respectively populate the “siaddr” and “file” protocol fields defined by RFC 2131); please note that these settings are not the same thing as options 66 and 67. Clients utilizing the Boot Server (“sname” protocol field) setting are much less common in our experience.

If you need to enter a value that contains backslash characters, they should be doubled, e.g. foo\\bar instead of foo\bar.

Exclusion Ranges

To exclude certain addresses within a DHCP Range from being dynamically assigned to clients:

  1. Choose the “Exclusion Ranges” subscreen in the Edit dialog (requires Advanced Mode).
  2. To add a new exclusion range:
    1. Click the Add (+) icon above the table to create a new row.
    2. Click the empty “Start Address” field in the new table row that appears, and type the first address to be excluded.
    3. Click the “End Address” field and type the last address in the range to be excluded. To exclude only a single IP address, enter the same value for Start Address and End Address.
  3. To remove an exclusion range:
    1. Select the checkbox to the left of the exclusion range to be deleted.
    2. Click the Delete (trash can) icon above the table.

Email Alerts

By default, the DHCP servers will automatically alert you by email whenever the current utilization of one of your DHCP Ranges exceeds 95% (and again when it drops back below 85%), with a maximum of one email alert per Range per day.  The recipient list for these emails is automatically populated (at the Network level) based on the network contacts listed in Contacts Database.

You may wish to add the following addresses to your email address book and/or safe senders list to ensure that DHCP utilization warnings are not filtered as spam:

  • no-reply@dhcp-a1.techservices.illinois.edu
  • no-reply@dhcp-a2.techservices.illinois.edu

sample message
From: <no-reply@dhcp-a1.techservices.illinois.edu>
Subject: DHCP high threshold crossed:

Message: DHCP high threshold crossed:
  Member: 192.17.2.10
  Network: 172.21.195.0/28/default
  Range: 172.21.195.7/172.21.195.14///default
  High Trigger Mark: 95%
  High Reset Mark: 85%
  Current Usage: 100%
  Active Leases: 5
  Available Leases: 0
  Total Addresses: 5

Reporting: DHCP
Node: 192.17.2.10
Time: Mon Mar  7 15:01:49 2018


Network Name: 0210-citesdhcp-net

Utilization graphs: 
https://ipam-tools.techservices.illinois.edu/dhcpmon/view.fcgi?subnet=0210-citesdhcp-net

Help: https://netwiki.techservices.illinois.edu/public/home/ipamdocs/using-ipam/dhcp-ranges-dynamic-pools/#Email_Alerts

You can customize the behavior of Email Alerts for this Range by choosing the “IPv4 DHCP Thresholds” subscreen in the Edit dialog (requires Advanced Mode).

  • To adjust the threshold values (or disable notifications altogether) for this Range, click the Override button for the “DHCP Thresholds” area.

    • Be sure to check both “Enable DHCP Thresholds” and “Enable Email Warnings” if you do still want to receive notifications.  Do NOT check “Enable SNMP Warnings”.

      screenshot

    • Note that actual utilization must be strictly greater than the High Trigger Mark (or strictly less than the Low Trigger Mark) in order to trigger an alert.

      Hint: do NOT set High Trigger Mark to 100. If you only want notifications when the range is completely full, set High Trigger Mark to 99.

  • To manually specify the list of email addresses which will receive threshold alert notifications for this Range (overriding the default recipient list for the Network), click the Override button for the “Email Addresses” area and populate the table as desired.
  • To return either area to its default behavior, click the corresponding “Inherit” button.

Restricting Access to a Range

By default, IP addresses in a DHCP Range can be dynamically allocated to any client machine that is connected to the appropriate network. To restrict the use of a DHCP Range to specific clients:

  1. Create a new MAC Address Filter and populate it with the desired MAC addresses (see MAC Address Filters), OR identify a suitable existing MAC Address Filter.

    You can use the same MAC Address Filter to restrict access to multiple DHCP Ranges.
  2. Choose the “Filters” subscreen in the Edit dialog for the Range (requires Advanced Mode).
  3. Click the Add (+) icon for the Class Filter List table, and select your MAC Address Filter.
    • By default the filter will be added with Action “Grant Lease”, meaning that clients matching this MAC Address Filter will be permitted (and clients not matching any MAC Address Filter listed in the Class Filter List will be denied).
    • If instead you want to deny leases to MACs matching this filter, click on “Grant Lease” and it will become a drop-down, then choose “Deny Lease” instead.

To return to the default behavior of permitting all clients, simply remove all Filters from the Class Filter List.

Advanced note: some use cases may involve adding an IPv4 Option Filter to the Class Filter List instead.  If a Class Filter List contains more than one type of filter (e.g. one or more MAC Address Filters AND one or more IPv4 Option Filters), then clients will be checked against the criteria for each filter type separately, and must satisfy them all in order to receive a lease.

Using Multiple DHCP Ranges

Best practice: avoid using more than one DHCP Range on the same network, unless each is intended for a different (non-overlapping) set of clients.

In most cases, you will want to create only one DHCP Range per network. If your network has a discontinuous collection of IP addresses which should be assigned interchangeably, it is better to create one large DHCP Range with Exclusions then to create several small DHCP Ranges which are otherwise identical, because Email Alerts apply individually to each Range.

It may make sense to create multiple DHCP Ranges if each one is intended to be used by a different (non-overlapping) set of clients.  If this is your goal, make sure that you associate at least one Filter with each Range.

Hint: if you configure one DHCP Range with action “Grant Lease” for a particular Filter, and a second DHCP Range with action “Deny Lease” for the same Filter, then any clients matching that Filter will be placed in the first range and all other clients will be placed in the second range.

Placing Fixed Addresses inside a DHCP Range

Best practice: avoid placing Fixed Addresses (or DHCP-enabled Hosts) inside a DHCP Range.

If you configure a Fixed Address (or DHCP-enabled Host) for an IP address that resides within a DHCP Range, it will function correctly (i.e. the IP in question will not be allocated to any other client).  However, the fixed address will be counted in the utilization statistics for the DHCP Range, which can be confusing and misleading – especially in the context of Email Alerts.

The simplest way to avoid confusion is to separate the IP addresses used for dynamic vs fixed allocations so they don’t overlap, but this may not be feasible if your net is full of legacy devices that can’t be easily moved.  In that scenario, your choices include:

  • Configure Exclusion Ranges for all IPs used by fixed addresses, so that they will not be counted as part of the Range.  This works well, but increases complexity (if you ever remove the fixed address, you must also remember to remove the exclusion before the IP will become dynamically assignable again).
  • Accept that your utilization statistics will be inaccurate, and consider adjusting Email Alert thresholds for a better practical outcome (e.g. if utilization currently hovers between 95-99%, increase High Trigger Mark to 99 so that you’ll still receive a notification if it ever hits 100%).
  • Decide that email alerts on this Range aren’t worth the trouble, and disable them.  (But be careful: this means new dynamic clients will just silently fail to get a lease if none is available, and you won’t have any indication why).

Reserved Ranges

If you set “Served by” to “None (Reserved Range)” instead of “IPv4 DHCP Failover Association”, then your range will be a Reserved Range rather than a DHCP Range.

Reserved Ranges provide no DHCP functionality; they are simply a way to label a group of addresses within the IPAM system (with the additional proviso that Reserved Ranges and DHCP Ranges can never overlap). See vendor documentation for more information about Reserved Ranges.

Note that addresses within Reserved Ranges will be counted (along with DHCP Ranges) in the DHCP Utilization statistics for the entire net, which can be confusing.  Workaround: Edit the Reserved Range and check “Disable for DHCP”.

Stand-alone DNS Records

This page contains information about creating and managing stand-alone DNS records.

Introduction

We use the term “stand-alone” to refer to any standard DNS record type (A, AAAA, CNAME, MX, SRV, TXT, etc) which does not have special proprietary behavior in Grid Manager.  There are many different types of stand-alone records, but the steps for managing them are very similar; we will discuss a few of the most common ones.

This page does not contain many screenshots, but some of the screenshots from the Host Records page may also be helpful here.

Stand-alone A Records

An address (A) record maps a fully-qualified domain name to a single IPv4 address:

www.example.com. IN A 198.51.100.17

Publishing multiple A records for the same name is legal and results in “round-robin DNS” behavior.

Best practice: use stand-alone A records only when you need an A record with no matching PTR (see below for further discussion). If you want a matching pair of A and PTR records, create a Host Record instead.

To create a stand-alone A record (with no matching PTR):

  1. Open the DNS Zone in which you want to create the new record (see Getting Started with IPAM).
  2. Click the dropdown arrow next to the Add (+) icon above the table in the main workspace, then choose “Record” and finally “A Record”.

  3. If necessary, click the “Select Zone” button and choose the zone which will contain the desired fully-qualified domain name (e.g. to create “myrecord.sandbox.illinois.edu”, you would select the zone “sandbox.illinois.edu”).

  4. Type the leading portion of the Name (e.g. “myrecord“) into the text box to the left of the selected zone name, so that both pieces together form the desired fully-qualified domain name.
    • You may leave this text box empty to create a record with the same name as the zone itself (e.g. “sandbox.illinois.edu”).
    • You may type e.g. “foo.bar” in the text box to create a record named “foo.bar.sandbox.illinois.edu” even if there is no zone “bar.sandbox.illinois.edu”.
    • You may type “*” or e.g. “*.bar” in the text box to create a record with a wildcard domain name (see RFC 4592).
  5. Enter the target IP Address to which your A record should resolve.
  6. Important: UNCHECK “Create associated PTR record”

    If you do want a matching PTR, you should Cancel this operation and create a Host Record instead.  Leaving this box checked creates a stand-alone A record and a separate stand-alone PTR record, which is undesirable because they can easily get out of sync in the future.
  7. Click “Save & Close”.

AAAA records are exactly like A records, but they target IPv6 addresses instead of IPv4 addresses.

www.example.com. IN AAAA 2001:db8::17

When should I use stand-alone A records?

Use stand-alone A (and AAAA) records when you do not want a matching PTR record.

Common reasons for this include:

  • the IP address already has a PTR record pointing to a different fully-qualified domain name

  • the IP address belongs to a network whose reverse-mapping DNS is not managed in IPAM

Otherwise, it is preferable to use Host Records (which automatically manifest as matching pairs of A/AAAA and PTR records).

Note that it is best practice to avoid creating multiple PTR records for the same IP address.  While not technically an error, this may cause problems for software which expects reverse lookups to return a single name (an expectation subtly encouraged by language such as “primary” and “the host name” in https://tools.ietf.org/html/rfc1035#section-3.5).

When you want several fully-qualified domain names (FQDNs) to resolve to the same IP address, the recommended best practice is:

  1. Create a Host Record for the FQDN that you consider to be primary.
  2. Where possible, implement each additional FQDN as a Host Alias or stand-alone CNAME record pointing to the primary FQDN.
  3. Create a stand-alone A record with no PTR for each additional FQDN which cannot be implemented as a CNAME record.

Example: Host Record for server17.mysubdomain.illinois.edu, stand-alone CNAME records (pointing to server17.mysubdomain.illinois.edu) for www.mysubdomain.illinois.edu and www.example.com, and stand-alone A records (pointing to the same IP as the Host Record) for mysubdomain.illinois.edu and example.com (which cannot be implemented as CNAME records since each resides at the apex of a zone).

MX Records

A mail exchanger (MX) record indicates the fully-qualified domain name of a mail server which can accept incoming email messages for a domain:

illinois.edu. IN MX 10 incoming-relays.illinois.edu.

Note that successful use of this record also entails resolving A (and/or AAAA) records for the mail server name.

To create an MX record:

  1. Open the DNS Zone in which you want to create the new record (see Getting Started with IPAM).
  2. Click the dropdown arrow next to the Add (+) icon above the table in the main workspace, then choose “Record” and finally “MX Record”.

  3. If necessary, click the “Select Zone” button and choose the zone which will contain the desired fully-qualified domain name (e.g. to create “myrecord.sandbox.illinois.edu”, you would select the zone “sandbox.illinois.edu”).

  4. Type the leading portion of the Mail Destination (e.g. “myrecord“) into the text box to the left of the selected zone name, so that both pieces together form the desired fully-qualified domain name.
    • You may leave this text box empty to create a record with the same name as the zone itself (e.g. “sandbox.illinois.edu”).
    • You may type e.g. “foo.bar” in the text box to create a record named “foo.bar.sandbox.illinois.edu” even if there is no zone “bar.sandbox.illinois.edu”.
  5. In the “Mail Exchanger” field, enter the target fully-qualified domain name of the mail server to which the MX record should point.

    Per RFC 2181, the target of an MX record MUST NOT be an (explicit) alias (i.e. a Host Alias or CNAME record).  You are responsible for following this rule; it is not enforced automatically.
  6. In the Preference field, enter a priority value for this record. (10 is selected by default)

  7. Click “Save & Close”.

Stand-alone CNAME Records

A CNAME record defines a static, explicit alias in the DNS which affects query behavior for all record types:

www.illinois.edu. IN CNAME illinois.edu.
  • Query: www.illinois.edu. IN A?
    Answer:

    www.illinois.edu. IN CNAME illinois.edu.
    illinois.edu.     IN A     192.17.172.3
  • Query: www.illinois.edu. IN MX?
    Answer:

    www.illinois.edu. IN CNAME illinois.edu.
    illinois.edu.     IN MX    10 incoming-relays.illinois.edu.

Common points of confusion:

  • This CNAME record helps your browser find the IP address of a web server for www.illinois.edu.  It does not tell your browser to redirect HTTP requests for http://www.illinois.edu/ to a different URL (only the web server itself can do that).
  • A CNAME record cannot coexist with other records (e.g. no other records are permitted at www.illinois.edu)

    RFC 1034: “If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different.”

    A few special record types for DNSSEC are exempted by later RFCs.

  • A CNAME record cannot be placed at the apex of a zone (e.g. illinois.edu).

    This follows from the previous point, because the apex of a zone is required to have NS and SOA records.

  • CNAME stands for “canonical name”, but that term (correctly applied) refers to the target name, not the alias name.  Best practice: use the terms “alias” and “target” to avoid confusion.

To create a stand-alone CNAME record:

  1. Open the DNS Zone in which you want to create the new record (see Getting Started with IPAM).
  2. Click the dropdown arrow next to the Add (+) icon above the table in the main workspace, then choose “Record” and finally “CNAME Record”.

  3. If necessary, click the “Select Zone” button and choose the zone which will contain the desired fully-qualified domain name of the alias (e.g. to create “myalias.sandbox.illinois.edu”, you would select the zone “sandbox.illinois.edu”).

  4. Type the leading portion of the Alias name (e.g. “myalias“) into the text box to the left of the selected zone name, so that both pieces together form the desired fully-qualified domain name.
    • You may type e.g. “foo.bar” in the text box to create a record named “foo.bar.sandbox.illinois.edu” even if there is no zone “bar.sandbox.illinois.edu”.
    • You may type “*” or e.g. “*.bar” in the text box to create a record with a wildcard domain name (see RFC 4592).
  5. In the “Canonical Name” field, enter the target fully-qualified domain name to which the alias should point. 

    The target of a CNAME record should not be another (explicit) alias.  So-called “CNAME chains” are not technically an error, but create inefficient behavior and are discouraged as a bad practice (see RFC 1034 sections 3.6.2 and 5.2.2).

  6. Click “Save & Close”.

When should I use stand-alone CNAME records?

A Host Alias is functionally equivalent to a stand-alone CNAME record pointing to the Host’s primary FQDN, but carries trade-offs with respect to ease of future maintenance.  Which option is preferable depends on the situation.

Advantages of using a Host Alias:

  • A Host Alias will automatically be kept up to date if you change the Host’s primary Name, whereas a stand-alone CNAME record will be left “dangling” if the target Host record is renamed or deleted.

Advantages of using a stand-alone CNAME record:

  • Modifying an existing stand-alone CNAME record to point to a different target is a simple one-step operation.  The corresponding process for a Host Alias requires editing the old Host (to remove the Host Alias) and then editing the new Host (to add the Host Alias).
  • If a Host Alias resides in a different zone (from the primary Name of the Host) which is not managed by the same set of people, the disparity in permissions may impede self-service changes to the record (possibly requiring an escalation to hostmgr).  A stand-alone CNAME record presents no such problem; it is governed by the permissions on the zone containing the alias name, while any target record(s) are governed by the permissions of the zone containing the target fully-qualified domain name.

    Best practice: always use a stand-alone CNAME record in the case where the desired alias name and the canonical (target) name reside in different zones which may not be managed by the same set of people.

Stand-alone PTR Records

A PTR record is a pointer to another fully-qualified domain name.  PTR records (unlike CNAME records) are simple data; they do not alter DNS behavior, may coexist with other records, and have no inherent special meaning.  Their significance is understood by convention from where they are placed in the namespace (e.g. “17.100.51.198.in-addr.arpa” is understood to represent the IPv4 address 198.51.100.17).

PTR records are most commonly used for reverse-mapping DNS (i.e. mapping from an IP address to a fully-qualified domain name).  In general, you should never create a stand-alone PTR record in IPAM for this purpose; instead, create a Host Record which will automatically manifest as matching pairs of A (or AAAA) and PTR records.

The rare exception to this rule occurs when you specifically need a PTR record for reverse-mapping DNS to point to a fully-qualified domain name whose forward-mapping zone is not managed in IPAM.

If you do need to manage stand-alone PTR records for reverse-mapping DNS, just Open the Network in IPAM View (see Getting Started with IPAM); it is not necessary to navigate the arpa zones.

Stand-alone PTR records in forward-mapping DNS zones (used infrequently for other purposes such as DNS-SD) are not a special case, and can be managed just like the other types of stand-alone records described on this page.

Editing Stand-alone DNS Records

  1. Navigate to the record you want to edit (see Getting Started with IPAM).
  2. Select the checkbox for the record and click the Edit (notepad) icon above the table. This opens the Edit dialog box.
  3. Make any desired changes.
  4. Click “Save & Close”.

Deleting Stand-alone DNS Records

  1. Navigate to the record you want to delete (see Getting Started with IPAM).
  2. Select the checkbox for the record (making sure no other checkboxes are selected), and click the Delete (trash can) icon above the table.
  3. If you’re sure, click “Yes” when the confirmation dialog appears.

Networking Public Home

This is the home page for the Networking Public wiki space, which is viewable by the general public.

sysLocation Format

Example:

r:2110A b:0210 c:c p:F71871 f:2 ra:2 z:5 ru:4 N:DCL #comment

Tools:

Semantics

Key

Priority

Description of Value

R

room

3 ⭐️

room “number” (actually string) where the device’s CER resides

B

building

1 ✅ 🔴

number of building where the device’s CER resides

C

cer

2 ✅ 🔴

string designator code (unique within building) of CER where the device is installed

P

pas

4 ✅

Property Accounting Sticker code for device

F

floor

number of building floor on which the device’s CER resides

RA

rack

5 ✅

number of rack (unique within CER) in which device is installed

Z

z

6 ✅

height (in rack units) at which the device is installed within the rack, with z:1 indicating the bottom position.

RU

ru

number of rack units the device occupies

N

nice

7

“nice name” by which CITES Networking refers to the building (not the official F&S building name)

✅: sysLocation is the authoritative source for this data
🔴: required for E-911
⭐️: not authoritative, but critically important to humans

Notes

Room is not authoritative, as it can logically be derived from building and cer (plus a table of information about known CERs). However, it is critically important to humans that the room value in sysLocation be present and correct, so that network support personnel responding to a page can easily track down a device using only the information from its saved config.

Note that cer is not derivable; there are some cases where a single room can contain more than one CER.

Floor is not authoritative, nor particularly important to humans reading sysLocation, and should probably be phased out over time.

Ru is actually a property of a device’s model (rather than of an individual device), could be derived from sysObjectID plus a table of known information about device models, and should probably be phased out over time.

Nice is a friendly nickname for a building which is made up internally by CITES Networking; it should never be treated as “authoritative” nor exposed externally, but its presence in sysLocation is useful to humans, and it is desirable that its value (for a given building) be consistent across devices.

Priority

We have discovered empirically that some devices limit the number of characters in the sysLocation field (e.g. to 48), and may silently fail to store a longer value.

When updating sysLocation for a device:

  1. Always double-check after setting sysLocation to verify that the desired value was in fact successfully stored!
  2. If the desired sysLocation string is too long for the device to accept, choose which fields to include based on the priority ordering given in the table.

Syntax

Unique prefixes of keys are permitted, with “r:” and “rm:” also signifying Room.

Keys and values are separated by ‘:‘, optionally surrounded by white space.

Empty values are permitted.

Key/Value pairs are separated by white space.

sysLocation may end with a comment, after white space followed by ‘#‘.

sysLocation may be all comment (no Key/Value pairs at all) if it begins with ‘#‘ or white space followed by ‘#‘.

The Nice value is case sensitive, may contain white space, may not contain ‘#‘ or ‘:‘, and must be last (if it is included).

All other Keys and Values are case insensitive, may not contain white space, may not contain ‘#‘, and may appear in any order.

Any excess white space may be removed from Nice values and from comments when parsing sysLocation.

World IPv6 Day – Urbana campus information

World IPv6 Day

What is World IPv6 Day?

World IPv6 Day is a 24-hour chance for service providers to test out IPv6 and see how it works in their environment. Major providers like Google, Facebook, Yahoo!, Akamai are using June 8, 2011 (GMT) as their test. For people on our campus, the official “day” will be 7pm on June 7th through 7pm on June 8th. The goal of this exercise is to see what is easy, what is hard, and what breaks when you turn on IPv6.

The website http://www.worldipv6day.org/ has more information on the World IPv6 Day.

What is IPv6 and Why do I care?

  • The short version is IPv6 is the next generation of IP addressing, since the world is running low on the current IPv4 addresses. Low enough that some users are only getting IPv6 addresses. You care because those users can only access your services through conversion systems, and those are out of your control. You don’t know what their user experience is and whether or not they think your service is poor because of that conversion. So you want your services native on IPv4 and IPv6 so that all users get the experience you planned for them.
  • CITES Networking and Security groups did a pair of presentations at the Fall 2010 IT Pro Forum about this. You can see the video here: http://itproforum.illinois.edu/2010Fall/schedule.php#2-B

What IPv6 services are available on the Urbana campus?

Urbana Campus Permanent IPv6 Services

  • Network Time (NTP)
  • Akamai (the caching servers are hosted on the ICCN network and serve all three campuses)
  • Network Backbone
  • ICCN (The regional network that connects Urbana with the other U of I campuses, the Internet, and R&E network providers like Internet2)

Urbana Campus Services being tested on World IPv6 Day

How to participate in World IPv6 Day

From the Urbana campus, you need to get on the IllinoisNet wireless SSID, and try things out. Android phones, some iPods and iPhones (running iOS 4), iPads, Windows laptops (native on Vista and 7, a patch is needed for XP to support IPv6) and Apple laptops (10.4.8 and later) should all be able to get IPv6 addresses and use them. If you haven’t connected to IllinoisNet before, you can get information on doing that at this webpage: http://www.cites.illinois.edu/wireless/wpa2/index.html

Once you are on IllinoisNet, go to a website like http://www.whatismyipv6.com/ and make sure you got an IPv6 address (if you didn’t, see the troubleshooting section below). Then try out websites like Google and Facebook see if you can tell a difference. Try the campus IPv6 websites listed above and make sure you can connect. You might want to try and see the “Dancing Turtle” which is a page that is only animated if you connect with IPv6 to this website: http://www.kame.net/ . If everything is going smoothly, you shouldn’t be able to tell you are on IPv6. Just do your normal email, web and other network things. For the servers and services testing IPv6 you’ll be providing them with data in their log files, in number of IPv6 users they served and if there are problems, by letting them know about them.

A handy tool for Firefox users is https://addons.mozilla.org/en-us/firefox/addon/showip/ which shows the IP address of the server you’re connecting to at the bottom of your window. you can quickly tell if you’re on an IPv6 server or not.

How to provide feedback on your IPv6 experience

  • ITPros can call 244-1000 to report problems or outages of any kind, whether or not they are related to IPv6
  • For less urgent feedback, ITPros can join the IPV6-USERS listserv and post feedback there
  • If you are not an ITPro then please send email to ipv6day-feedback@ct-mail.cites.uiuc.edu with your feedback.

Troubleshooting IPv6

I didn’t get an IPv6 address, how do I get one?

  • First make sure you are connected to IllinoisNet wireless as your only network connection
  • Then make sure you haven’t turned IPv6 off on your system
  • Windows XP users might need to install a patch. http://support.microsoft.com/kb/2478747
  • If you are on IllinoisNet and have IPv6 enabled but still aren’t getting an address you can stop by our World IPv6 Day table just outside the CITES Help Desk in DCL from 10am to 4pm on June 8th and someone will help you figure out why it isn’t working.

I got an IPv6 address but I can’t get to any of the IPv6-only pages

  • If you have time, come to our table just outside the CITES Help Desk in DCL from 10am to 4pm on June 8th and someone will help you figure out why it isn’t working.

I got an IPv6 address but now nothing works

  • Follow the instructions for turning IPv6 off below.
  • If you have time, come to our table just outside the CITES Help Desk in DCL from 10am to 4pm on June 8th and someone will help you figure out why it isn’t working.

I got an IPv6 address and something are working but others aren’t

  • Follow the instructions for turning IPv6 off below.
  • If you have time, come to our table just outside the CITES Help Desk in DCL from 10am to 4pm on June 8th and someone will help you figure out why it isn’t working.

How to turn IPv6 off

CITES multicast information

Multicast usage on campus is growing, and CITES is working hard to make the underlying networking system for multicast more stable. In order to do this we will need some help from the departmental IT Professionals.

If you’re not familiar with multicast and how it works, please take a minute or two to read this UIUCnet multicast basics document on the CITES website:

http://www.cites.illinois.edu/network/advanced/multicast.html

Here’s what CITES has already done and what we have in progress:

We have updated our campus edge multicast filters to the current best practices list based on information gathered from Abiline and other I2 institutions. These filters keep us from sending out to the rest of the world things like our Ghost and Retrospect Remote traffic, and also keeps us from getting that traffic in from other places. We are blocking well known “problem” multicast addresses like Norton Ghost, as well as all reserved addresses that are not allocated for use at this time. For a complete list of what we are blocking at the campus edge, please see the end of this email. If there is an address we are blocking that you have a need for, please contact multicast@uiuc.edu and we will work with you to enable the groups you need.

We worked extensively with our core router vendor to make changes to their multicast routing behavior so that it would work in a supportable way in our environment. At this time we believe that the core routers support of multicast is up to the every-day use of multicast.

We have setup an “anycast” style Rendezvous Point (RP) on the campus side of the firewalls for responsiveness to things on campus (and for functionality incase of an exit issue) and one on the far side of the firewalls to use for multicast peering to other institutions. This will remove the RP as a single point of failure for on-campus use, since either can take over if one is not working. the campus side RP is offline due to software issues. We are working on returning that to service.

CITES is also working with our various hardware vendors where we have found multicast problems to be sure that the vendor knows about the issues we are seeing and are working on a fix.

CITES Network Designers are making sure that IGMP snooping is turned on for all newly deployed devices to be sure that multicast isn’t flooded throughout the building networks by default. They are also working with net admins to turn on IGMP snooping in existing equipment where it is not already on. If you would like to request multicast to be enabled for your network please have the networking contact for the subnet mail ndo@uiuc.edu with your request.

CITES has moved to a default of turning multicast routing on for a newly created subnet so that multicast features can be used by the IT Professionals and the Unit’s users. Any Unit can choose to leave multicast off, and any Unit with an existing subnet that does not have multicast on can request it be turned on.

To request a multicast address send email to multicast@illinois.edu and describe what you’re doing, how long you need the address for and whether it should be a global address to a limited-to-campus address.

As mentioned above here’s a list of multicast groups that are blocked at the campus exits. For those of you not familiar with the details of the exits, NCSA is on the far side of these connections, and so these groups are also blocked to NCSA.

inbound to campus information on the following groups:

224.0.1.1
224.0.1.2
224.0.1.3
224.0.1.8
224.0.1.22
224.0.1.24
224.0.1.25
224.0.1.35
224.0.1.39
224.0.1.40
224.0.1.60
224.0.2.1
224.0.2.2
224.1.0.38
224.0.0.0 0.0.0.255
224.77.0.0 0.0.255.255
224.128.0.0 0.0.0.255
225.0.0.0 0.255.255.255
226.0.0.0 0.255.255.255
227.0.0.0 0.255.255.255
228.0.0.0 0.255.255.255
229.0.0.0 0.255.255.255
230.0.0.0 0.255.255.255
231.0.0.0 0.255.255.255
234.0.0.0 0.255.255.255
235.0.0.0 0.255.255.255
236.0.0.0 0.255.255.255
237.0.0.0 0.255.255.255
238.0.0.0 0.255.255.255
239.0.0.0 0.255.255.255

outbound from campus traffic blocked on the following groups:
10.0.0.0 0.255.255.255 any
127.0.0.0 0.255.255.255 any
169.254.0.0 0.0.255.255 any
172.16.0.0 0.15.255.255 any
192.168.0.0 0.0.255.255 any

CSV Imports and Exports

Introduction

The CSV Import feature of Grid Manager provides one way to perform “bulk” updates which create, modify, or delete many DNS and/or DHCP objects at once. Not every imaginable use case is supported, but most common tasks are fairly straightforward.

Caution: it is not possible to “undo” or roll back a CSV import after it is executed!

When in doubt, we highly recommend using development IPAM for proof-of-concept testing.

Note that you can also perform “bulk” updates programmatically using the IPAM API; the advantages and disadvantages of each approach vary depending on the nature of the task at hand.

Creating CSV Data Files for Import

For your convenience, Technology Services has created ready-made template data files for a number of common tasks, which can be used for their intended purpose just by reading and following the instructions on this page.

If you wish to adapt any of the templates for other purposes, or to create your own data files from scratch, please refer to CSV Import Reference in the vendor documentation.

Performing a CSV Import

Once you have created a CSV data file, use the following steps to import your data file into Grid Manager:

  1. Click “CSV Import” on the Toolbar panel to bring up the CSV Import Wizard.
  2. Choose the desired import type:
    • Add
      Adds a new Grid Manager object based on the data in each row (will fail if an object with the same required field values already exists).

    • Override
      Uses the required field values in each row to select an existing Grid Manager object (will fail if no suitable object exists), then overwrites any other attributes of that object specified in the remaining columns.
    • Merge
      Uses the required field values in each row to select an existing Grid Manager object (will fail if no suitable object exists), then fills in any attributes specified in the remaining columns for which the object does not already have a value.
    • Delete
      Uses the required field values in each row to identify and delete an existing Grid Manager object.
    • Custom
      See vendor documentation.
    • Replace
      See vendor documentation; use with caution.
  3. Click “Next”.
  4. Click the “Choose…” button and choose a CSV file to upload.  The file name should appear in the text box.
  5. Optionally select how Grid Manager should behave “On error”.

    Note: no matter which behavior you select, any rows before the first error row will always take effect.
  6. Click “Next”.
  7. The first few rows of your data file should appear in the preview area (separated into columns); make sure it looks reasonable.
  8. Click “Import” to begin the operation.

    Note: if you click “Save & Close” at any point prior to clicking “Import” in this step, your job will be saved but not executed.  See Managing Existing CSV Jobs (below) to find it again.

  9. The “CSV Import Progress” window will appear, showing the current status of your job (probably “Import pending”).
  10. You may wait here for your job to complete; when it does (typically within about 30 seconds), the current status will change to “Import successful” or “Import unsuccessful”.
    Alternatively, you may click “Close & Run in Background” to dismiss the dialog box and work on something else while you wait; see Managing Existing CSV Jobs (below) to find it again.
  11. Once the job has completed, check the “Rows with errors” counter to see if any errors were generated.
    • If so, click the “Download Errors” button to retrieve another CSV file containing the error rows (prepended with their corresponding error messages).
    • Remember: any rows from your original CSV file that did not produce errors will still have been imported!
  12. Click “Close” to dismiss the dialog.

Managing Existing CSV Jobs

Click “CSV Job Manager” on the Toolbar panel to display a table containing your CSV jobs submitted within the last 30 days.

Use the hamburger menu icon in each table row and click “Edit” to open the Edit CSV Import Job dialog box, which includes an “Import” button to execute the job.

Grid Manager allows you to Edit a job which has already been executed and click Import to execute that same job again without re-uploading the file, but if you do so, the information about the previous run (timestamps, error file, etc) will no longer be available in CSV Job Manager.  It is usually preferable to start a new import job instead.

You can also use the hamburger menu to Delete a job which has not yet been executed, or Download the Error File from a job which terminated unsuccessfully.

Templates

The following templates are available to help you perform common tasks via CSV Import.

Each template contains at least one header row which can be used exactly as provided, followed by one or more sample object rows which should be modified (and more rows added if necessary) to reflect the actual data you wish to import. The header row beginning with e.g. “HEADER-Foobar” tells Grid Manager how to interpret the columns of the corresponding object rows beginning with e.g. “Foobar” (which must be a valid object type).

Some templates include columns whose values are described as optional; you may safely choose to leave these columns blank when filling in your object rows.

  • Create new DNS-only Host Records
    Type: Add
    Importing this spreadsheet will create a new Host Record for the FQDN in each row, with the specified IPv4 and/or IPv6 address(es) and Host Aliases. You must specify at least one address. The “aliases”, “EA-Property Tag” (Property Tag extensible attribute) and “comment” values are optional. Host records created using this template will not be enabled for DHCP.
  • Create new DHCP-enabled Host Records
    Type: Add
    This template expands on the previous one to create new Host Records whose IP addresses are also enabled for DHCP. Each new Host record to be created needs multiple CSV rows:
    • one “HostRecord” row specifying the FQDN and all of its associated IPv4 and/or IPv6 addresses (as well as optional “aliases”, “EA-Property Tag”, and “comment” values)
    • zero or more “HostAddress” rows to enable the DHCP checkbox and specify the associated MAC address for each individual IPv4 address within the Host
    • zero or more “IPv6HostAddress” rows to enable the DHCP checkbox and specify the associated DUID for each individual IPv6 address within the Host
  • Enable DHCP for Existing Host Addresses
    Type: Override
    For each row, “parent” and “address” must match the FQDN and an IPv4 or IPv6 address of an existing Host record in IPAM. Importing this spreadsheet will enable the DHCP checkbox for that IP address and overwrite its associated MAC address or DUID (as described in Adding DHCP to a Host record).
    Hint: you can obtain names and IP addresses of existing Host records on a network (to use as a starting point) by opening the Network in IPAM view and exporting visible data.
  • Add IP Addresses to Existing Host Records
    Type: Add
    For each row, “parent” must match the FQDN of an existing Host record in IPAM. Importing this spreadsheet will assign an additional IP address to that Host record. Optionally, you may choose to enable DHCP for newly added IP addresses.
  • Create Stand-alone DNS Records
    Type: Add
    Use this template to create new Stand-alone DNS Records of various types. Each type has its own header row; please omit any unused header rows from your data file. All “comment” values are optional.

    Keep in mind that Host Records are often (but not always) preferable to stand-alone A and AAAA records.

  • Importing this spreadsheet will create a new DHCP Fixed Address with the IP address and MAC address or DUID specified in each row. The “EA-Property Tag” (Property Tag extensible attribute) and “comment” values are optional.

  • Add MAC Addresses to a MAC Address Filter
    Type: Add
    Importing this spreadsheet will add the MAC address in each row to the MAC Address Filter whose name appears in “parent”. The “registered_user”, “EA-Property Tag” (Property Tag extensible attribute), and “comment” values are optional.
  • Modify Existing Stand-alone DNS Records
    Type: Override
    For each row, the required fields (indicated with asterisks) must match an existing Stand-alone DNS Record in IPAM.  Importing this spreadsheet will modify that record according to the values specified in the remaining columns.  To modify a required field such as the address of an A record, specify the old value in “address” and the new value in “_new_address” (leave “_new_address” blank if you don’t want to change the address). Each type has its own header row; please omit any unused header rows from your data file.

Exporting data from Grid Manager

Many tables in Grid Manager can be exported as a downloadable CSV in two different ways, using the drop-down menu for the Export (up arrow) button:

screenshot

  • Choose “Export visible data” to download a CSV containing precisely the columns and values that are actually visible within the current table (i.e. as shown on the screen, except that all pages of the table are included).
  • Choose “Export data in Infoblox CSV Import Format” to download a full CSV representation of the Grid Manager objects that appear in the current table, including all of their configuration attributes.

Other tables in Grid Manager provide only a single Export button with no drop-down menu; this is equivalent to “Export visible data” as described above.

You can restrict which rows (objects) are included in the CSV by applying a Filter to the table beforehand.

DHCP Fixed Addresses

Introduction

A DHCP Fixed Address makes a particular IP address available for use exclusively by a single designated client.  For as long as the Fixed Address is configured, the designated client will always receive this IP address when connected to the appropriate network, and this IP address will never be allocated to any other client.  For DHCPv4, the designated client is identified by MAC address; for DHCPv6, it is identified by DUID (DHCP Unique Identifier – see also Limitations of DHCPv6 fixed address allocation).

From the client’s point of view, obtaining a lease from a Fixed Address is exactly the same as obtaining a lease from a DHCP Range.

On the server side, however, there is an important difference: fixed addresses are timeless, which is to say that the server’s behavior does not take into account whether the IP address in question was previously leased (either to the same client or to a different client).  This has two practical consequences for the careful network administrator wishing to avoid an operational conflict:

  • Avoid configuring a Fixed Address for an IP which currently has an Active lease belonging to a different client (unless you are certain that the old client is no longer on the network).
  • Avoid configuring a Fixed Address for an IP which very recently had a Fixed Address belonging to a different client (unless you are certain that the old client is no longer on the network).

Stand-alone Fixed Addresses vs DHCP-enabled Host records

The stand-alone DHCP Fixed Address objects described on the remainder of this page are DHCP-only objects with no DNS component.

You may alternatively wish to consider enabling DHCP for an IP address within a Host record, which is functionally equivalent to creating a stand-alone Fixed Address but makes it easy to keep the DNS and DHCP configuration for a client in sync (in case you later decide to migrate the client to a different IP address or retire it altogether).

Best practice: in general, use DHCP-enabled Host records instead of stand-alone DHCP Fixed Addresses.

Reservations

You may notice that it’s also possible in IPAM to create a “Reservation” object.  This is not the same thing as a Fixed Address, and will not accomplish what you probably intend; a “Reservation” in IPAM is a placeholder which does not permit any DHCP client to use the IP.

Users familiar with Microsoft DHCP should note that a Microsoft DHCP “Reservation” is analogous to a Fixed Address in IPAM, not a “Reservation”.

Creating a DHCP Fixed Address

To create a new stand-alone DHCP Fixed Address:

  1. Using either DHCP View or IPAM View, Open the Network in which you want to add a fixed address (see Getting Started with IPAM).
  2. Optionally (if using IPAM View), select the checkbox next to the desired IP address.
  3. Click the dropdown arrow next to the Add (+) icon above the table in the main workspace, then choose “Fixed Address”.
  4. Click “Next” at the bottom of the dialog window.
  5. Enter the desired IP address.

    If you have opened a Network in IPAM View and selected an IP address in the main workspace, it will automatically be pre-populated for you.

  6. For IPv4 addresses: ensure that “MAC Address” is selected, and enter the MAC address of the client that will use this IP.
  7. For IPv6 addresses: enter the DUID (DHCP Unique Identifier – see also Limitations of DHCPv6 fixed address allocation) of the client that will use this IP.
  8. Optionally, you may use the Name field to specify an internal display name for this Fixed Address object.

  9. Click “Save & Close”.

Please note that your network must have autoconfiguration service appropriately enabled (see Requesting DHCP for Networks) in order for creating a DHCP Fixed Address to have any effect.

Editing a Fixed Address

To edit an existing stand-alone DHCP Fixed Address:

  1. Navigate to the Fixed Address you want to edit (e.g. by opening its Network in DHCP View, or opening the individual IP address in IPAM View to display Related Objects – see Getting Started with IPAM).
  2. Select the checkbox for the Fixed Address object, and click the Edit (notepad) icon above the table.
  3. Make sure to enable Advanced Mode for the dialog.
  4. Make any desired changes.
  5. Click “Save & Close”.

Note that you can configure custom DHCP options that will apply only to this individual fixed address (but are otherwise similar to Setting DHCP Options for a Range).

Deleting a Fixed Address

To deleted an existing stand-alone DHCP Fixed Address:

  1. Navigate to the Fixed Address you want to edit (e.g. by opening its Network in DHCP View, or opening the individual IP address in IPAM View to display Related Objects – see Getting Started with IPAM).
  2. Select the checkbox for the Fixed Address object (making sure no other checkboxes are selected), and click the Delete (trash can) icon above the table.
  3. If you’re sure, click “Yes” when the confirmation dialog appears.

Host Records

Introduction

A Host record allows a single primary Name (fully-qualified domain name) to be associated with any of the following, managed collectively in Grid Manager as a single database object:

  • one or more IPv4 addresses, which manifest as matching pairs of A and PTR records
  • one or more IPv6 addresses, which manifest as matching pairs of AAAA and PTR records
  • one or more Host Aliases, which manifest as CNAME records pointing to the primary name
  • optional DHCP fixed address configuration for each IP address

Host records provide several advantages compared to managing an equivalent collection of Stand-alone DNS Records, the most important of which is that if you change one part of a Host record, the other parts will automatically update to stay in sync.

The trade-off is that you must be VERY careful when deleting a Host record!

Best Practice Recommendations:

  • In general, use Host records instead of stand-alone A, AAAA, and PTR records, except when you do not want matching pairs.
  • Do not create multiple Host records for the same IP address.
  • Use stand-alone CNAME records instead of Host Aliases if the desired alias name resides in a different zone (from the primary name) which is not managed by the same set of people.
  • In general, use DHCP-enabled Host records instead of DHCP Fixed Addresses.

For more information, see When should I use stand-alone A records? and When should I use stand-alone CNAME records?

Creating a Host record

To create a new Host record:

  1. Open the DNS Zone which will contain the desired primary name.  (alternative: open a Network in IPAM View and select the desired IP address).  Opening Zones and Networks is described in Getting Started with IPAM.
  2. Click the dropdown arrow next to the Add (+) icon above the table in the main workspace, then choose “Host”, and finally “Host” again.

    screenshot

    This opens the Add Host dialog box. (alternative: in IPAM View click Add, then “Host”, then “New Host”)

  3. If necessary, click the “Select Zone” button and choose the zone which will contain the desired primary name (e.g. to create “myhost.sandbox.illinois.edu”, you would select the zone “sandbox.illinois.edu”).

    If you opened a DNS zone in the main workspace, it will be automatically pre-selected for you.

  4. Type the leading portion of the Name (e.g. “myhost“) into the text box to the left of the selected zone name, so that both pieces together form the desired fully-qualified domain name.

    screenshot

    • You may leave the text box empty to create a record with the same name as the zone itself (e.g. “sandbox.illinois.edu”).
    • You may type e.g. “foo.bar” in the text box to create a record named “foo.bar.sandbox.illinois.edu” even if there is no zone “bar.sandbox.illinois.edu”.
  5. If necessary, add one or more IPv4 Addresses to your Host: click the drop-down arrow next to the Add (+) icon just above the IPv4 Addresses table and choose “Add Address” to place a new row in the table, then click the IPv4 Address field in that row and type the desired IPv4 address. Press return or click elsewhere when you are done typing.

    screenshot

    If you opened a Network and selected an IPv4 address in the main workspace, it will be automatically pre-populated for you.

    Adding more than one IPv4 address to a Host will create multiple matching pairs of A and PTR records for the same primary Name, resulting in “round-robin DNS” behavior.

  6. If necessary, add one or more IPv6 Addresses to your Host.
  7. Add a comment in the “Comment” field (optional).
  8. Click “Next” at the bottom of the dialog window.
  9. If desired, add one or more Extensible Attributes (e.g. “Property Tag”).

  10. Click “Next”.
  11. If desired, you may schedule this change to occur at a later time instead of taking effect immediately (see Scheduled Tasks).
  12. Click “Save & Close” at the bottom of the dialog window.

Editing a Host Record

Before changing the primary Name of a Host record, it is advisable to perform a Basic Search by DNS Name for the current primary Name (fully-qualified domain name), in order to identify any Stand-alone DNS Records (CNAME, MX, etc) pointing to it.

  1. Navigate to the Host record you want to edit (see Getting Started with IPAM); you can find it either by name or by IP.
  2. Select the checkbox for the Host record and click the Edit (notepad) icon above the table.

    screenshot

    This opens the Edit Host dialog.

  3. Make any desired changes (several possibilities are discussed below).
  4. Click “Save & Close” at the bottom of the dialog window.

Adjusting TTL

For changes to high-profile DNS records (e.g. migrating a live production service), Technology Services recommends that you temporarily lower the TTL of the record in question (e.g. to 1 minute) at least one hour prior to making the actual change, and then restore the TTL to the campus default (1 hour) after the change is complete and you have confirmed that everything is working properly.

To set a custom TTL for a Host record:

  1. Choose the “TTL” subscreen in the Edit dialog.
  2. Click “Override” next to the TTL value, and enter the new desired value (e.g. 1 Minute).

    screenshot

  3. Click “Save & Close”.

When your high-profile change is complete, Edit the record again and click “Inherit” on the same TTL subscreen to resume using the campus default.

screenshot

 

You may find it helpful to add the TTL column to the table of Records in a Zone.  Note that this column only displays customized TTLs; it is left blank for records which inherit the default TTL.

Adding Host Aliases

A Host Alias is functionally equivalent to a stand-alone CNAME record which points to the Host’s primary Name, but carries trade-offs with respect to ease of future maintenance.  For more information, see When should I use stand-alone CNAME records?

To add a Host Alias to a Host Record:

  1. Choose the “Aliases” subscreen in the Edit dialog

  2. Click the Add (+) icon to place a new row in the table, then click the Aliases field in that row and type the new fully-qualified domain name that should point to this Host.  Press return or click elsewhere when you are done typing.

    screenshot

  3. Click “Save & Close”.

Enabling DHCP for Host addresses

Enabling DHCP within a Host record is functionally equivalent to creating a stand-alone DHCP Fixed Address, but makes it easy to keep the DNS and DHCP configuration for a client in sync (in case you later decide to migrate the same client to a different IP address or retire it altogether).

To enable DHCP for an IP address in a Host record (either while adding a new Host record or while editing an existing one):

  1. Click the DHCP checkbox to the right of the desired IP address.

  2. For IPv4 addresses: click the “MAC Address” field in that row and type the MAC address of the client that will use this IP.  Press return or click elsewhere when you are done typing.

    Click here to expand…

  3. For IPv6 addresses: click the “DUID” field in that row and type the DHCP Unique Identifier (see also Limitations of DHCPv6 fixed address allocation) of the client that will use this IP.  Press return or click elsewhere when you are done typing.
  4. Optionally, you can also select the IP address using the checkbox to its left and then click the Edit (notepad) icon above the table to configure custom DHCP options that will apply only to this individual fixed address (but are otherwise similar to Setting DHCP Options for a Range).  Hint: don’t forget to enable Advanced Mode for the sub-dialog.
  5. Click “Save & Close”.

Please note that your network must have autoconfiguration service appropriately enabled (see Requesting DHCP for Networks) in order for enabling DHCP within a Host record to have any effect.

Displaying Host records in a Zone

When displaying Records within a Zone (see Getting Started with IPAM), we recommend that you click “Toggle flat view” so that each manifestation of a Host record is displayed in its own table row.  After you click it, the link text changes to “Toggle hierarchical view”.  It should look like this:

screenshot

If you instead choose to display Records in hierarchical view, the Host record will appear only as a single row for the primary Name, and any Host Aliases in other zones will not be visible at all when displaying the contents of those zones.  This view is not recommended, as it may cause you to overlook important data.

screenshot

Managing DHCP Leases

This page contains instructions for viewing and clearing DHCP Leases.

Introduction

A DHCP Lease represents a DHCP server’s knowledge that a particular IP address has been allocated to a particular client for a specified period of time.

Note: because of the way DHCP Failover works, each dynamically allocated IP address actually has two corresponding Lease objects in Grid Manager – one for each DHCP server in the failover pair.

Grid Manager may also display “Static” Lease objects for IP addresses that have been assigned to a client via DHCP Fixed Address (or DHCP-enabled Host); note that these behave differently from regular Leases because fixed addresses are timeless.

Displaying Leases

There are three different ways to display Leases in Grid Manager. In all cases, the Lease objects on the servers are updated in real time; use the Refresh icon at the bottom of the window to see the latest data.

Viewing Leases in a single DHCP Range

You can view all free and assigned Leases in a particular DHCP Range by opening the Range object:

  1. In DHCP View, Open the DHCP Network to which the DHCP Range belongs (see Getting Started with IPAM).
  2. Open the Range by clicking on its address range displayed in the IP Address column.

    You can add the MAC Address column to this table.

Any “Static” Leases for IP addresses within the DHCP Range will also be included.

To see the details of an assigned Lease, select it and choose “Lease Details” from the toolbar panel on the right.

Viewing Leases in a Network

You can see the status of each IP address on a Network, including whether it is currently assigned as a Lease, by opening the Network in IPAM View (see Getting Started with IPAM).

Known Issue: in IPAM view, “Static” Leases are only displayed if the IP in question happens to fall within a DHCP Range.

The Lease State and MAC Address are visible in columns of the table (if you have selected List display).

To see the full details of an assigned Lease:

  1. Open the IP address (in List display), or select it on the graphical map (in IP Map display).
  2. Select the Lease from the Related Objects table.
  3. Choose “Lease Details” from the toolbar panel on the right.

Viewing all Leases in all of your Networks

You can view all Lease objects on all of your Networks at once (including “Static” Leases) by navigating to Data Management > DHCP > Leases > Current Leases using the rows of tabs at the top of the screen.

screenshot

This is by far the slowest method of examining Leases, because Grid Manager has to check every Lease object in its database against your individual user permissions in order to determine which ones should be displayed.  Performance can be improved by using a Filter to narrow the scope of your interest; for example,

  • IP Address belongs to “192.168.0.0/26” (pictured in screenshot above) for a CIDR match, or
  • IP Address begins with “192.168.0.” for a plain string match.

Known Issue: when you first click on the Current Leases tab, you may need to wait up to 2 minutes for the unrestricted search to time out before you can successfully apply a Filter.

Note that free addresses which do not have Lease objects yet (because they have never been assigned to a client) will not be displayed in this view.

To see the details of an assigned Lease, select it and click the Lease Details (paper) icon above the table.

Clearing Leases

The DHCP protocol specification does not empower the server to revoke a client’s lease once it has been issued.

However, you can force the DHCP servers to forget that a lease has been assigned (thereby making it available for assignment to other clients) by selecting it and clicking “Clear Lease” from the toolbar (in IPAM view, click the drop-down arrow next to “Clear” and then choose “Clear Lease”).

Use extreme caution when clearing leases, as it may cause IP address conflicts on your network!

Even after a lease has been cleared in Grid Manager, the client is within its rights to continue using the allocated IP address until the original expiration time.

In general, you should clear a lease only if you are absolutely certain that the client has been removed from the network.

Note that “Static” Leases cannot be cleared this way, but will be automatically removed by Grid Manager if you modify your DHCP configuration in a way that would permit the IP in question to be allocated to a different client.

Abandoned Leases

An Abandoned lease marks an IP address which is configured for DHCP dynamic allocation but has been abandoned by the DHCP server as unfit for use, due to one of the following occurrences:

  • After receiving a DHCPDISCOVER, the server selected this IP address to be offered, but received a response to its ping check.
  • After sending a DHCPACK for this IP, the server received a DHCPDECLINE message from the client indicating that the IP address is already in use (typically because the client issued an ARP request for the IP address and received a response, as described in RFC 2131 section 4.4.1).

Abandoned leases do not expire but remain Abandoned indefinitely, at least until the supply of Free/Backup leases becomes exhausted.  When a DHCPDISCOVER is received and there is no Free/Backup lease available to fulfill it, DHCP will automatically attempt to reclaim one Abandoned address and offer it to the new client (after performing the usual ping check).  However, if the reclaimed address is still in use, it will be marked Abandoned again and no DHCPOFFER will be sent, meaning the client will fail to obtain a lease (even though there might be other Abandoned addresses which aren’t actually still in use – in that case, future DHCPDISCOVER attempts by the same or other clients will eventually fare better).

What to do about Abandoned leases:

  • Try to avoid them in the first place by making sure that clients on your network are correctly configured to use DHCP and, if your network includes any manually-configured devices, making sure that DHCP is not configured to hand out those IP addresses.
  • If you do accumulate a significant number of Abandoned leases, identify any addresses which are not actually still in use on the network, and manually Clear them from Grid Manager.

    Hint: to see only the Abandoned addresses within a particular network, open the Network in IPAM view (as in Viewing Leases in a Network above), and apply Filter: Lease State equals Abandoned