The Hardware Address Last in IP ARP Data (HALIAD) facility allows you to search recent IP ARP data collected by OIT. Specifically, you may search for a hardware address in that data, to learn the most-recent date on which that hardware address appeared. For example, you might use HALIAD to learn that hardware address 0:01:23:4a:b:dc last appeared in the IP ARP data collected by OIT on October 15 2007.
To search for a hardware address in HALIAD, visit the Hardware Address Last in IP ARP Data (HALIAD) Search page. Access is restricted to Web clients in the princeton.edu DNS domain, and also requires you to login using an OIT netid and password.
OIT provides HALIAD in response to requests from technical support staff who wish to have access to this data. We do not expect the facility to be used by most customers; its intended audience is technical support staff who understand what an IP ARP cache is.
The remainder of this document provides detailed information about HALIAD. While you need not read this information to use HALIAD, you may need this information to correctly interpret the results provided by HALIAD. There are a surprising number of technical details regarding what information HALIAD can and cannot provide. Without understanding them, it is easy to misinterpret HALIAD. For example, it would be an error to interpret the absence of a device's hardware address from HALIAD as clear indication that the device is not attached to the network.
To search for a hardware address in HALIAD, visit the Hardware Address Last in IP ARP Data (HALIAD) Search page. Access is restricted to Web clients in the princeton.edu DNS domain, and also requires you to login using an OIT netid and password.
On most OIT networks, a daily record is made of all the topologically reasonable IPv4 addreses that were in-use (even briefly) on that day.
Specifically, we mean that some device used ARP to say "I'm using this IPv4 address" at some point during the day, and that at that time, the device was attached to the IP subnet appropriate for that IP address. Or that a DHCP server offered a lease on that IPv4 address to the client, in response to a DHCPDISCOVER from the client. Or that a DHCP server awarded a lease on that IPv4 address to the client, in response to a DHCPREQUEST from the client in DHCP INIT-REBOOT state. Or that the client performed Detection of Network Attachment (DNAv4) with that IP address as its claimed IP address, while it was attached to the IP subnet appropriate for that IP address.
Shortly after each day begins, we process the ARP data collected during the previous day, using it to update HALIAD.
HALIAD only records the most-recent date that a hardware address was seen in the IP ARP data. It does not record a history of use. When you search HALIAD, you can only learn the most-recent date the hardware address was seen.
HALIAD data more than approximately two years old is discarded. If you search HALIAD for a hardware address that has not been seen in the IP ARP data for more than approximately two years, you will not find it in HALIAD.
If you search HALIAD at the start of the day, before the previous calendar day's ARP data has been incorporated into HALIAD, the most recent IP ARP data available to HALIAD will be two days old. Once the previous day's IP ARP data has been incorporated into HALIAD, the most recent data available to HALIAD will be one day old. HALIAD does not include data from the current calendar day.
The results of a HALIAD search will show what period is currently included in the HALIAD data; for example, "March 17 2006 - March 16 2008". This information is displayed regardless of whether the hardware address you specified was found in the HALIAD data.
For the technically inclined, here are more details:
HALIAD does not store the IP address; in fact, within a single day one hardware address may have used multiple IP addresses. HALIAD's only interest is that the hardware address used some IP address during the day.
HALIAD also does not store the time of day of that usage; it only records the date, overwriting old dates with newer dates.
HALIAD relies on the IPv4 ARP data collected from some traditional OIT IP routers. As a result, there are certain things it cannot know about:
Because there is no OIT IP router, we cannot collect a reliable IP ARP cache for these networks. As a result, when a device is attached to one of these networks, its presence will normally not be reflected in HALIAD.
Networks that fall into this category include: arbor-tms-net-1, astro-net-1, astro-net-2, basnet2, beepbeepbeepnet, cryptnet, cryptnet2, ctl-pstn-net-1, ctl-pstn-net-2, eis-firewall-heartbeat-1, expressnet, fac-cub-bopfb, fac-cub-bopio1, fac-cub-bopio2, fac-cub-plc-p2p1, fac-cub-plc-p2p2, fac-cub-plc, fac-cub-scada-p2p1, fac-cub-scada-p2p2, fac-cub-scada, fac-tgr-bopfb, fac-tgr-bopio1, fac-tgr-bopio2, fac-tgr-dtsfb, fac-tgr-plc, fac-tgr-scada, fac-tgr-plc-p2p1, fac-tgr-plc-p2p2, fac-tgr-scada-p2p1, fac-tgr-scada-p2p2, fw-*-ha1, fw-*-ha1-backup, fw-*-ha2-ha3, f5-heartbeat-1, hbrnet, iacnet, ideanet, infutor, infranet8, ip4-evpnloopback, ip4-fac-egn-selnet, ip4-gp-on-prem-ha1-a, ip4-gp-on-prem-ha1-b, ip4-gp-on-prem-ha2, ip4-hci-hpcrc-federation, ip4-hci-ns-federation, ip4-hci-hpcrc-storage, ip4-hci-ns-storage, ip4-hpcrcbasnet, ip4-loopback-*, jumbo-net, lightnet, lightnet2, lsiscope-net-1, papyrusnet, pingpongnet, ppnnet, ppn-vss-testnet, promax-net-1 russnet, sbc-heartbeatnet-*, skeletonnet, smilenet, smilenetqa, stellanet, telegraphnet, tgardner-net, valetnet, viewnet, viewnet2, voltnet, and wattnet.
Networks that fall into this category include: fw-vipnet-*, fw-servernet-*, fw-vipnet-*, fwzone-dev-*, ip4-rcosproto-1, ip4-rcosproto-2, ip4-seczone1-*, ip4-seczone2-*, lb-servernet-*, lb-vipnet-*, and stagenet.
Networks that fall into this category include: (none).
Networks that fall into this category include: fac-bop, fac-bop-epsn, fac-cems, fac-cems-eppn, fac-cog-plc, fac-cog-scada, fac-cwt-fb1, fac-cwt-io1, fac-cwt-plc, fac-cwt-scada, fac-enp, fac-enp-epsn, fac-icetec, fac-icetec-eppn, fac-enp-private-nat, fac-enp-public-nat, fac-opc, fac-opc-epsn, fac-termis, fac-termis-eppn, ip4-fac-elecmon-nat, plinknet12, plinknet16, plinknet24, oit-eis-aws-supernet-0001, oit-eis-azure-supernet-0001, and science-dmz-net.
Because there is no OIT IP router, we cannot collect a reliable IP ARP cache for these networks. As a result, when a device is attached to one of these networks, its presence will normally not be reflected in HALIAD.
Networks that fall into this category include: ip4-cisco-uc-di-qa, ip4-fac-pmweb.
This doesn't mean that the device must be "actively used" to appear in HALIAD. Even a device attached to the network with no one "actively" working with the device will still speak IP; throughout the day, the device will likely respond to many network scans and other queries.
(Of course, if the device has actually "gone to sleep" such that it turns off its network interface, it will not be reflected in HALIAD; from the network's point of view, that's little different from a device that's powered off. Similarly, if the device has "gone to sleep" such that it brings down its IP service, the device will not be reflected in HALIAD, as HALIAD is based on IP ARP data.)
Such a layer two firewall might be a standalone piece of hardware, or a software-based firewall on the device itself. Either way, if it is configured in such a way as to block the ARP traffic between the device and the OIT IP router, that will prevent the IP address from appearing in the OIT IP router's ARP cache, and therefore prevent it from appearing in HALIAD.
Operating a layer two firewall in such a way would be unusual (and would likely cause other problems for the device), but we mention it here because some customers might still do something this unusual.
For example, if the device's Ethernet interface is attached via an OIT Ethernet switch port, and OIT has disabled the Ethernet port to which the device's Ethernet interface is attached, we will not see traffic from the device's Ethernet interface.
Or if the device is trying to use a wireless service provided by OIT, but is not successfully connecting to the wireless network, the device will not appear in HALIAD, because it is not actually connected to the campus network.
Or if the device is trying to use wired dynamic service, but the device is not able to use the service because it is not registered for the service, the device will not appear in HALIAD, because it will not be using a topologically appropriate IP address for the network to which it is connected.
Or if the device is attached to VLAN foonet, and OIT has blocked the device's hardware address at a core Ethernet switch for VLAN foonet, this may prevent the OIT IP router for foonet from seeing the device's IP ARP traffic.
An IPv4 device only stores in its ARP cache IP addresses that are topologically reasonable, given the device's notion of the IP network range. Therefore, when a device attached to network foonet tries to use an IP address that's inappropriate for use on foonet, that usage will not appear in the IP ARP cache of the OIT IP router serving foonet. Since it doesn't appear in the ARP data, it doesn't appear in HALIAD.
This commonly happens if a device configured to use an IP address appropriate for use on network barnet relocates to a different network foonet, but is configured so that it continues to try to use the old barnet IP address. (Of course, the old barnet IP address won't work.)
OIT's responsibility for external customer networks is primarily to provide working physical connectivity, and to operate the OIT IP router leading to the Internet. OIT doesn't actively monitor or manage the external customer networks at a higher layer.
Based on this information, you should be able to see that you cannot conclude that a device is not attached to the campus network just because its hardware address doesn't appear in HALIAD, There are a variety of common situations above in which a device may indeed be attached to the campus network, but not appear in HALIAD. (Of course, in some of these situations, the device is physically attached but not receiving useful network service.)
This limits the usefulness of HALIAD; when it shows a hardware address appears in the recent IP ARP data, it confirms that the hardware address has been attached to the network recently. But when it shows a hardware does not appear in the recent IP ARP data, one can draw no conclusion as to whether the device has been attached to the network recently. Despite this limitation, we make HALIAD available in response to requests from technical support staff who wish to have access to this data.
HALIAD has no direct relationship to the Network Registration. HALIAD simply reads the IP ARP Data we obtain from IP routers; it doesn't care whether the IP addresses and hardware addresses in that data happen to appear in Network Registration.
This means, for example, that deleting an entry from Network Registration does not cause the device's hardware address(es) to be discarded from HALIAD. Nor does adding an entry to Network Registration cause hardware address(es) to be added to HALIAD. There's no direct relationship between Network Registration and HALIAD.
This is intentional; Network Registration and the routers' IP ARP tables are entirely different things. And it's perfectly reasonable to be able to delete an entry from Network Registration, and later wish to see when one of that entry's hardware addresses was last in the recent ARP data.
(For the technical inclined: there can sometimes be an indirect relationship between Network Registration and HALIAD. For example, consider a device obtaining an IP address via OIT-provided DHCP service in a manner that relies on the device being registered in Network Registration. Once that device's entry is deleted from Network Registration, the device may no longer obtain an IP address via OIT-provided DHCP service. Once the device is no longer able to obtain an IP address, and it stops using an appropriate IP address, it will stop appearing the OIT IP router's IP ARP cache. That will cause the device's "last seen" date in HALIAD to stop changing; HALIAD will continue to show the last date the hardware addresse used a topologically valid IP address. Assuming the device continues to not use a topologically valid IP address, its HALIAD record will eventually be discarded after approximately two years. So the removal of the entry from Network Registration influenced the HALIAD data, but in an indirect fashion.)
OIT recognizes that providing information about the usage of a network device can raise privacy concerns. We believe that HALIAD addresses these concerns because the information HALIAD provides is deliberately limited: