Problem solve Get help with specific problems with your technologies, process and projects.

Router Expert: Conducting a network inventory, part 2

Learn how to easily create and analyze a network inventory report.

Read about Michael

In Part 1 of this series, I covered the process of collecting data for a network inventory. Next comes the part that I claimed was a "snap" -- generating a nice inventory report.

Before we go any further, however, I wish to clarify and revise my remarks. First, the good news is that the report will actually look better then it did in the last article. That's because, rather than go through a laborious file consolidation process, we now have a Perl script to do the work for us. Of course, to get a lot sometimes you need to give a little. In order to use the report script, you need to use an updated script, which formats the data a little differently than the older version. This change is well worth it, because the report script yields a nice tab-delimited file that can be imported into Excel to create this beautiful report:

IP MAC OID DNS 0000.0c07.ac05 CISCO SYSTEMS INC. 0004.ac5e.4810 IBM CORP. obiwan, 000b.cd83.53f6 Unknown OUI 0008.02a1.4d80 Compaq Computer Corporation 0001.812b.fe08 Nortel Networks Unresolved 0005.5fe7.0800 Cisco Systems Inc. Unresolved

This eliminates the need for running a bunch of separate text formatting processes and using the esoteric Unix diff command. To get started, you should have a collection of files similar to the ones listed here:

Trinity$ ls

Here's a quick review of how you got these files:

  • Vlan-list-*.txt is the output of the script. It generates a list of a router's physical interfaces or a switch's VLAN interfaces, which you can use to determine which networks you should audit.
  • *-IPdump-date.txt is the report output of with the "-ir" flag that generates an IP address table from a router or Layer 3 switch.
  • *-dnsdump-date.txt is the output of the *-acthost-date.txt is the output of the script, a shell script that calls fping to perform an ICMP ping scan against an IP address range.
  • *ARPdump-date.txt is the output of with the "-ar" flag that generates an IP and MAC address table from a router or Layer 3 switch.
  • oui-join.txt is the output of This is a wrapper script for the Perl script that resolves the OUI portion of the 48-bit Ethernet MAC address.

To generate the inventory report, only the acthost, arpdump, oui-join, and dnsdump data files are needed. Use the reporting script The command syntax is < acthost> < arpdump> < oui-join> < dnsdump>: Here is a CLI example:

Trinity: # perl 172.30.71-acthost-01-24-05.txt 172.30.71-
ARPdump-outlan-rs01-01-24-05.txt oui-join.txt 172.30.71-dnsdump-01-24-05.txt
Trinity: # 

When the script has completed its run, it reports "Done" to the CLI and exits. The report names are derived from the network designation associated with the acthost file. In the case that one of the report source files is missing from the CLI, the script errors with "Cannot open file" and exits.

Trinity: # perl 172.30.71-acthost-01-24-05.txt 172.30.71-
ARPdump-outlan-rs01-01-24-05.txt oui-join.txt 
Cannot open file 
Trinity: # 

Before we go on to the reports the script generates (and why), there is one last thing you must keep in mind. The order in which the script reads the file is not flexible. The files must be processed in the following order if you want an accurate report:

  1. acthost
  2. arpdump
  3. oui-join
  4. dnsdump

If the files are not processed in the correct order, a report will generate but with incorrect data. Here is an example where the dnsdump and oui-join files have exchanges places:

Trinity: # perl 172.30.71-acthost-01-24-05.txt 172.30.71-
ARPdump-fny-rs01-01-24-05.txt 172.30.71-dnsdump-01-24-05.txt oui-join.txt 
Trinity: #

The script has generated a report, but take a look at the output:

Trinity: # more
IP      MAC     OID     DNS     0000.0c07.ac05  Empty   ->   0004.ac5e.4810  Empty   ->    000b.cd83.53f6  Empty   ->    0008.02a1.4d80  Empty   ->    0050.8b2c.f25e  Empty   ->

Compare the above to what the output should look like:

Trinity: # more 172.30.71_consolidated_report.txt
IP      MAC     OID     DNS     0000.0c07.ac05  CISCO SYSTEMS INC.           Unresloved   0004.ac5e.4810  IBM CORP.     000b.cd83.53f6  Unknown                      OUI    0008.02a1.4d80  Compaq Computer Corporation    0050.8b2c.f25e  COMPAQ COMPUTER CORPORATION

This happens because the script is comparing the data in each of the files and parsing it into a set of reports, expecting certain values. If and when they are not there it reads this missing data as either valid or an error and reports on it. If data is there, but it's the wrong data, it also reports on it. It's a slippery slope because you want to see inconsistencies in the data, but you are not always sure what those will be. You also don't want to constrict the function of the script by requiring that the input files meet some explicit criteria. Just remember that the files must be processed in the correct order if you want the report to be correct.

What does all of this data provide us with? The reporting aspect of the network inventory should yield three things:

  1. A listing of all the active hosts on an IP subnet at the time the inventory was run
  2. Information on inconsistencies between ICMP collection and the router/switch's visibility of the subnet
  3. Inconsistencies between what is active on the subnet and what is in DNS.

There is also a fourth aspect that has value, depending on the environment: network hardware information, which can assist in the reading of the results of the network audit data to determine some of the validity of the findings and assist in the configuration of the network vulnerability scan tests. After all, the more you know, the more confident you can be in the findings. To help meet the above reporting criteria, the script generates three files:

  • *_consolidated_report.txt is just what its name implies, a consolidation of all of the inventory data in a single report, including IP information, ARP information, OUI information and DNS information.
  • *_dns_err_report.txt is a list of IP addresses to hosts that do not have any DNS information. This report can mailed off to the hostmaster so the the problem can be fixed.
  • *_icmp_err_report.txt is the differential between the IP host data gathered by the ICMP scan and the ARP table report. Normally this report should be empty. If for some reason an inconsistency does come up, you may have to use Unix diff after all.

The IPdump report is used to resolve inconsistencies found in the *_icmp_err_report.txt file. Using the Unix diff command, the IPDump and acthost files need be compared. Here is a syntax example:

Trinity$ diff *-IPdump*.txt *-acthost*.txt

This command compares the findings of the active IP hosts in the ARP table to those found using the ICMP ping scan. If a difference should come up, it will usually be hosts missing in the "acthost" file. This is due to either ICMP filtering on a router gateway or some kind of local ICMP handling rules. Diff operates using file A -> file B comparison. It looks at the two files and makes suggestions on how file A can be changed be the same as file B. So the "master" file should be file B. Diff reports its change recommendations using "c" to indicate a change is needed on a line, "a" where an addition is needed to a file at a specific line, or "d" where a line needs to be deleted. Needless to say, it takes some practice to easily work with diff, due to its esoteric output.

Let's take a look at the results of the "acthost" (which is the file we want the output to match) to "ipdump" (which is the file that "acthost" should match to):

Trinity$ diff 172.30.100-acthost-12-05-04.txt 172.30.100-IPdump-fny-rs01-12-

To make comparing a little easier, here is what the two files look like side by side:

The 2a2 output from diff means that the line 3 of the "IPdump" file needs to be added after line 2 in "acthost" file. In terms of our inventory, we need to investigate why did not respond to ICMP, aside from gateway or local ICMP filtering. The host could also no longer be active (with its ARP entry still stuck in the ARP table) or it could be that the host simply did not respond in time.

The 10c11 output from diff indicates that there is a mismatch between line 10 on the "acthost" and line 11 on the "IPdump" file (assuming that you have corrected the first difference). Diff recommends that line 10 be changed to reflect line 11. In terms of the audit, however, this represents another point to investigate. The ARP table sees a host, and the ICMP scan sees a host This could indicate that host is behaving similar to As for host, it responded to ICMP, but is not in the ARP table. If the ICMP scan was run from a host connected to the target subnet, it is possible that the host could have just come online and had not yet forwarded a packet off the subnet yet. In that case, the gateway would have not seen any traffic from the host and would not have registered the MAC in its APR table.

Of these two examples, the former will be far more common. I use them to illustrate the point that there will be instances where the data from the two reports will not be in sync and you'll need to do some investigation to resolve the issue. Whenever discrepancies arise, the first action to take is to verify that the "odd" hosts are reachable. Then rerun the ICMP scan and arpdump and compare the results again. If the problem continues to exist, check to see if the "odd" host is running filtering software or has a local policy for responding to ICMP traffic. If all else fails, clear the ARP table on the router or switch using the exec command <clear ip arp> and rerun the tests again. Hopefully, you will not run into this problem often. But if you do, it should be investigated. This kind of scenario is also an indicator of a rouge access point or network monitoring point.

Now you've completed your network inventory are ready to run your network services audit. Stay tuned for the next steps in the process. In the meantime, if you have questions, comments, or article suggestions, please e-mail us.

>> Miss the first part in this series? See Conducting a network inventory, part 1
>> For more information on the entire audit process, read the article, Why you need a network services audit.

This was last published in February 2005

Dig Deeper on Network Infrastructure

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.