DEVELOPMENT SERVER: content may be inaccurate

Other Tools

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.

Networking Public Home

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

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

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.