Router Expert: Conducting a network inventory, part 1

Peforming a network inventory is the first step to an audit. It allows you to build a complete picture of your environment and will reveal inconsistencies that should be resolved.

Read about Michael

Before a network services audit can begin, a network inventory must be conducted. An inventory includes collecting

host identification information, such as IP address, network interface hardware (NIC) address and DNS entries, for all network nodes. While some of this information will be on hand in most environments, often it will have errors. In most cases, NIC information and MAC addresses will not be recorded.

Even if you think you have the information, it's a good idea to conduct the inventory and verify the information as a first step to an audit. This allows you to build a complete picture of the environment and, as an additional benefit, will reveal inconsistencies that should be cleaned up. The approach covered in this article assumes you have administrative access to the network you are auditing. The open source scripts provided run in Unix/Linux, Apple's OS X, and Cygwin for Windows environments and work on IOS-based switches and routers supporting SSH or RCMD access.

Collecting inventory attributes
Before we get into the process, it's a good idea to think about why we are interested in IP, MAC and DNS information. When working with nodes connected to network users and administrators, we typically use either host IP addresses or DNS entries to establish communications and exchange data. Both of these identification methods were designed to be user-friendly and easy to manage. They frequently assigned human names (and numbers) to help us interact with distinctly non-human machines. Both schemes were designed in the late seventies, when serial terminals were the primary means of computer interaction and the original ARPANET host table was a file that was e-mailed around.

The dynamic nature of the two methods, in terms of allocation and implementation, has allowed them the flexibility to support both global and private operating models. However, it is this dynamic nature that makes them problematic from a security perspective. Because the assignments are dynamic and transferable, different physical hosts can assume the same "network identity." Most network-based attacks leverage IP and DNS's unverifiable nature. Distributed denial-of-service (DDOS) attacks disable the legitimate host and allow the attacker to assume the victim's IP identity. ID fishing e-mails use bogus URLs to redirect unsuspecting users to fake sites that capture personal identity and financial account information.

Only NIC MAC addresses are unique, because they are associated with the host's NIC, rather than the host. The majority of today's workstations and servers have built-in network interfaces, making the MAC address an ideal network attribute to use for tracking and access control (via Layer 2 filtering and/or static DHCP). This is not to say MAC addresses are foolproof; if an attacker has access to the local network, ARP/MAC spoofing is possible. And if a server were replaced due to failure, its MAC information would also change. So, while no tracking method is perfect, tracking (and controlling access using) the MAC, IP, and DNS attributes is one of the best means of verifying and ensuring the continuity of the network.

Host identification information sources and method
To start, pull out that spreadsheet, notepad or whatever you use to document the nodes on your network. You will use this information as control data. An ideal auditing environment works from the perspective of verification: We are verifying what we already believe to be in place. If this data does not previously exist, the first audit will serve as a baseline for comparison to future audits.

As we discussed above, the host inventory collects three data points: IP address, MAC address and DNS entries. At the end of the inventory, we should have an inventory dataset that looks something like this:     0000.0c07.ac05  CISCO SYSTEMS,   0004.ac5e.4810  IBM CORP.    000b.cd83.53f6  Unknown OUI    0008.02a1.4d80  Compaq Computer    0050.8b2c.f25e  COMPAQ COMPUTER    0002.a528.b2b3  Compaq Computer   0008.c7f4.4655  COMPAQ COMPUTER    000b.cd50.786a  Unknown OUI    0008.c72a.c8fb  COMPAQ COMPUTER     0001.812b.fe08  Nortel Networks     0005.5fe7.0800  Cisco Systems,

A table like this should be created for each segment in the network. So far, we have discussed three of the four attributes above. The data points in the third column are the organizationally unique identifiers (OUI) for each of the MAC addresses. The first 24 bits of each Ethernet MAC address is the hardware manufacturer's OUI, which has been assigned by the IEEE. A manufacturer uses its OUI in combination with a unique 24 bit value to create a unique MAC address for each network interface.

Knowing the OUI of a network node can assist in tracking and troubleshooting misbehaving hosts. In the early days of networking, NICs were an additional component added to the computer, requiring the MAC address to be tracked and associated with a host for useful tracking. Today, most hardware manufacturers provide one or more on-board network interfaces, so resolving a host's MAC OUI can in many cases identify the type of hardware connected to the network and, by extension, the type of operating system.

Once the inventory is complete, subsequent inventories can be run and compared, allowing you to easily identify changes and errors so you can investigate and correct them. All of this data can be collected off the network; no access to the nodes is required. The data for inventory is collected by extracting data from the network's switch and router ARP and interface tables, DNS zone dumps, and ICMP ping scans. The ARP and ICMP scans provide information on active IP hosts. DNS zone and interface tables provide information about the IP networks within the administrative domain, along with hostname information. While each data source provides a unique piece of the puzzle, they also provide redundant information that can be compared to the other sources to ensure accuracy and reveal any inconsistencies.

The tools
To run the following scripts, you will need a computer capable of supporting Perl, SED, awk, sh, sort, date, diff and grep. You will also need to download and compile domainscan and fping. (Fping is a ping replacement that supports a number of scanning and output options, making it a great tool for admins who rely on ICMP for troubleshooting.) The scripts function as program wrappers that extract and format your inventory data so that it is easily accessible. Here are overviews of each of the scripts, explaining the programs they depend on and what they do:

  • -- This Bourne shell script uses SSH to fetch a list of a router's physical interfaces or a switch's VLAN interfaces. It builds a list of IP networks connected to the router or switch that you can use to determine which networks you should audit. It also helps identify devices against which to run ARP dumps.
  • -- This Bourne shell script also uses SSH to fetch an IP address or IP address and ARP table from an IOS-based router or switch. ARP tables must be pulled from devices that have direct connections to the network segments for which you are collecting ARP information (ideally the default gateway for the segment). If not, the ARP entries for the IP addresses you query will result in the physical interface the router or switch uses to reach the target hosts.
  • -- This is a Bourne shell script that calls domainscan to perform a DNS lookup on a Class C network. It formats the output for comparison and data merge with the output of the other tools. For best results, run using the network segment's root DNS server and a secondary DNS server and compare the results. If you have hosts that are publicly accessible, you will want to compare your DNS root entries against other public DNS servers to make sure the data is consistent.
  • -- This is another Bourne shell script that calls fping to perform an ICMP ping scan against an IP address range. Normally you would use it on a Class C network with 255 IP addresses or less. Larger scans will work, but the data become hard to manage. Like, the command output from fping is formatted to be used with the other scripts.
  • -- This is a Perl script that resolves the OUI portion of the 48 bit Ethernet MAC address. The script gets its input from the arpresolv.txt file. This file is generated when is run to generate an ARP table dump with option to have the command output saved to a file.
  • -- This is a Bourne shell wrapper script for the Perl script. It formats the output for merge with the report data from the other scripts.

Collecting the network inventory data
The most effective way to build an inventory is one IP subnet at a time. Each network has its own logical layout, but every network uses one or more subnets. That makes the IP subnet the smallest logical unit with which to work. If you are auditing your own network, there is no need to run, because you should already know the subnets that make up your network. However, if you are forgetful, or not familiar with the section of the network you are auditing, pull the interface or VLAN list from the gateway device using the command. The script opens a SSH session to the device. You are prompted for your password, and the command output is sent to the CLI and saved as a text file (for reference). On an IOS-based router, use the ¡Vr command flag, and on an IOS-based switch use the ¡Vv flag. If you have a question on the syntax, run the command followed by the ¡Vh flag. The full command syntax looks like this: <username> <host> {-v|-i}. Here is a CLI execution example:

Trinity# ./ amin out-rs01 -v
amin@out-rs01's password: 
The Report Name is: Vlan-list-out-rs01-10-21-04.txt

Once you have a list of subnets, select a segment and collect the DNS records for the subnet using the script. Like vidump, this script opens an SSH session to the device. You will be prompted for a password before the command executes. The command will, by default, dump the output to the CLI. Use the ¡Vr flag to save the data to a report file. The full command syntax looks like this:<> {-r}. The following example scans the 172.30.100 subnet and saves the output to a report file:

Trinity# ./ 172.30.100 -r
Report 172.30.5-dnsdump-12-05-04 Complete!

After the DNS information has been collected, the next step is to find active hosts on the IP subnet. While it may seem obvious to some, running an IP host inventory against an IP subnet that uses dynamic DHCP will provide very little useful information. It will give you with a snapshot of the hosts connected, but that data will only be valid as long as the hosts stay connected and/or the leases expire. It is possible to "spot audit" hosts by correlating the ARP dump data from the switch and the lease table from the DHCP server to fingerprint hosts, but that is a topic for another article. For now, let's suffice to say that inventories should be run against subnets where the IP assignments are statically assigned (or allocated via DHCP).

The goal here is to conduct an audit of the network services running on the servers connected to the network. A list of active hosts is built using the script. The script must be run as root or with a root equivalent ID on a Unix/Linux system, because fping needs to be run as root. The command sends the command output to the CLI by default and will save it to a report file with the ƒ{r flag after the IP network range statement. The full command syntax looks like this: (start IP) <> (end IP) <> {-r}>. Here is a CLI output example:

Trinity # ./ -r 
The report name is
Trinity # 

After running the ICMP collection using, we must generate two more IP host reports, one listing the active IP hosts and one listing the active IP hosts and their respective MAC addresses. The IP "only" report from the gateway device in most cases will provide redundant information with respect to the report generated by However, there will be instances where a host may respond very slowly or not at all to the ICMP request, because the host has filtered or disabled ICMP. The IP gateway ARP table does not suffer from these drawbacks, because any host on the IP segment that transmits data on or off the segment must have a valid MAC entry in the switch/router's ARP table.

The script can direct its output to the CLI or to a report. Unlike the other scripts, it can either dump the entire IP or ARP table or just the IP or ARP information for a specific IP subnet or VLAN by providing the IP prefix or VLAN ID following the report flag. To complete the data collection for our host inventory, we need to collect both the IP and ARP data for the target IP subnet. To generate the IP table, we use the ¡Vi flag to send the output to the CLI or the ¡Vir flag to send the output to the CLI and a report file. To generate the ARP table, we use the ¡Va flag to send the output to the CLI or the ¡Var flag to send the output the CLI and a report file.

The default for all the output options generates a report listing every entry in the ARP table. This list can be quite large, especially if traffic bound for Internet hosts passes through, because the router/switch will assign the MAC address of a gateway as it forwards Internet-bound traffic and for each Internet IP address. To make the reports more manageable, you can specify searches based on IP subnet prefix or VLAN ID following the report flag. The full command syntax looks like this: <username> <host> {-a|-ar|-i|-ir} <string>. Here is an execution example collecting data on the active IP hosts:

Trinity # ./ admn outlan-rs01 -ir 172.30.100
admn@outlan-rs01's password: 
Connection to outland-rs01 closed by remote host.
Collection Complete.
Formatting Data...
Active IP Host Table for 172.30.100 on outlan-rs01 Completed... 
Report Saved as 172.30.100-IPdump-outlan-rs01-12-05-04.txt
Trinity #

Here is the output of an APR table report for the same subnet using the VLAN ID as the search string:

Trinity # ./ admn outlan-rs01 ¡Var Vlan5
admn@outlan-rs01's password: 
Connection to outland-rs01 closed by remote host.
Collection Complete.
Formatting Data...
ARP Table for Vlan5 on outlan-rs01 Completed...     0000.0c07.ac05   0004.ac5e.4810    000b.cd83.53f6    0008.02a1.4d80    0050.8b2c.f25e    0002.a528.b2b3   0008.c7f4.4655    000b.cd50.786a    0008.c72a.c8fb     0001.812b.fe08     0005.5fe7.0800

Report Saved as Vlan5-ARPdump-outlan-rs01-12-05-04.txt Created arpresolv.txt for

The OUI translation report must be run last. There are two scripts involved, and Both scripts operate under the same principle. They read the contents of the arpresolv.txt. They resolve the OUI portion of the address and perform lookups against the Web site using the curl program. The generates the following CLI output:

Trinity $ perl 
looking up OIDs. -> Nortel Networks -> COMPAQ COMPUTER CORPORATION -> Nortel Networks -> Compaq Computer Corporation -> CISCO SYSTEMS, INC. -> Unknown OUI -> Unknown OUI -> COMPAQ COMPUTER CORPORATION -> COMPAQ COMPUTER CORPORATION -> DITECH CORPORATION -> COMPAQ COMPUTER CORPORATION -> COMPAQ COMPUTER CORPORATION -> Cisco Systems, Inc. -> IBM CORP. -> Compaq Computer Corporation
Trinity $

The script runs the and formats the output, sending it to the CLI and saving it to a file named oui-join.txt. The oui-join.txt file data is one of the data sets that is merged with other report data to complete the network inventory report. Here is an output example of the script:

Trinity: $ ./     CISCO SYSTEMS,   IBM CORP.    Unknown OUI    Compaq Computer    COMPAQ COMPUTER    Compaq Computer   COMPAQ COMPUTER    Unknown OUI    COMPAQ COMPUTER     Nortel Networks     Cisco Systems,     Nortel Networks     DITECH CORPORATION    COMPAQ COMPUTER    COMPAQ COMPUTER
Trinity: $ 

Once you have collected all of the data, building the report is a snap. At this point, you should have a collection of files similar to the ones listed here:

Trinity$ ls
172.30.100-IPdump-fny-rs01-12-05-04.txt Vlan-list-outlan-rs01-12-05-04.txt
172.30.100-dnsdump-12-05-04.txt          Vlan5-ARPdump-outlan-rs01-12-08-04.txt        oui-join.txt

Now that we have collected all of the host identification data, you're ready to cross-reference the data sets and build the network inventory report. We'll cover that in next month's article. In the meantime, if you have questions, comments, or article suggestions, please e-mail us.

For more information on the entire audit process, read last month's tip, Why you need a network services audit.

This was first published in December 2004

Dig deeper on IP Networking



Enjoy the benefits of Pro+ membership, learn more and join.



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: