About sorting of 'host' and 'domain'

Host Domain Descending order, click to reverse IP Address MAC Address Other
192.168.xxx.1 Local 192.168.xxx.1 00:E0:18:xx:xx:xx
pooh Local 192.168.xxx.2 00:60:97:xx:xx:xx
xmlrpc.rhn.redhat.comLow Risk Flag for (ISO 3166 code) us (from p2c file)  
www.ford.com Flag for (ISO 3166 code) us (from p2c file)  
www.ford.co.uk Flag for (ISO 3166 code) us (from p2c file)  
3COM CORPORATION:E2:DB:06     00:10:4B:E2:DB:06



The 'hosts' column is actually a composite of many items of information tracked and discovered by ntop for display. This field contains the best information we have as to the name of a host, be that a DNS resolved name, an IP address, a MAC address or something else.

Because it is a composite, a simple alphanumeric sort (0, 1, 2, 3 ... a, b, c ...) is not used. It is perfectly normal, and correct, to see - as in the example above - a host 'name' beginning with "w", such as www.burtonstrauss.com followed by one beginning '3COM', which is normally earlier in an alphanumeric sort. The first level of sorting is by the type of the item and the second is alphanumeric (or numerical or whatever makes sense) within types.

This means - for example within an ascending sort - that all DNS names will be in alphabetical order. Following the DNS names comes IP addresses (sorted in numerical order so that follows After IP addresses come other types of items in sequences appropriate to their types.


The actual value displayed in the hosts column may be further processed as part of creating the actual html link. These affect the displayed value, but NOT the sort sequence.

The most visible of these changes is that all MAC addresses are NOT sorted as their native 48-bit quantities. There are cases where ntop recognizes a special MAC code (such as Spanning Tree Bridge) or recognizes the vendor code from the IEEE OUI (Organizational Unique Identifier) list and adjusts the displayed information. These adjusted names will appear followed by the last 24 (unique) bits, e.g. as 3COM CORPORATION:ff:ff:ff, and are sorted without regard to upper and lower case, so that all of a vendors assigned ranges of network cards should be sorted together. In reality, the IEEE list often has multiple forms of the vendors name, and so there will not be a perfect sort. Unrecognized prefixes will be sorted after recognized ranges according to a numeric compare of their 48-bit values. Note that if the actual 48-bit value not displayed, it is visible as a tooltip (title) by hovering the mouse over the link.


Finally, it is possible for items to be listed (and thus sorted, before ntop has come to a final decision about the 'name'. These items are sorted last, based on the underlying fields ntop maintains about each host. This can look 'odd' - wait a minute or so and resort - things should clear up.



A similar situation applies to sorting the 'Domain' column. This column is sorted in alphabetic sequence of the two character ISO 3166 code (e.g. US for United States, CA for Canada, DE for Germany), followed by local entries.

A flag value of local shows that the IP address is part of the RFC 1918 (http://www.faqs.org/rfcs/rfc1918.html) "Address Allocation for Private Internets") address ranges,, and These are typically addresses assigned by a LAN, corporate or ISP's DHCP server to enable NAT (Network Address Translation, as defined by http://www.faqs.org/rfcs/rfc1631.html).

Domains which are equal are sorted - as fall-backs - by 1) the full domain name (i.e. stripped of the 1st qualified) and then 2) the host value.

Unfortunately, the fall-back criteria are also not immediately set, and so the domain column sort may be 'odd' in appearance until the data stabilizes. You have seen this effect if you have noticed that at first domain entries seem out of sequence and that it may take a while for the flags to appear in the column. This is annoying but perfectly normal.

But the flag data is wrong!!!!

You will notice that there may not be much correlation between the last qualifiers (e.g. .com or .co.uk) and the country flag shown. This is because ntop uses data from various sources to map an IP address such as to it's physical location. And, frankly, their data isn't very good.

The primary source are the regional number registries:

We also include Tier 1 registry data from Cable & Wireless - because the registry data at the regional registries is so messed up. Similar data might be available for other Tier 1 ISPs - tracking down the files is the hard part - start the search at http://www.irr.net/docs/list.html and/or RADB - ftp.radb.net.

Still - this data is often wrong or incomplete. Perhaps more frequently, a web site is hosted somewhere different than you might think or is distributed around the world (and you are seeing a local mirror) or is part of a private block, where the subdivisions are simply not known.

For example, Ford.com makes sense tagged as "US" since that's where Ford's headquarters is located. However ford.co.uk, also "US", seems odd. If one looks up the ip address, you find that the entire block is assigned to Ford Motor Company with a US address:

02/28/04 09:48:05 IP block
Trying at ARIN
Trying 136.8.154 at ARIN

OrgName:    Ford Motor Company 
OrgID:      FORDMO
Address:    P.O. Box 2053, RM E-1121
City:       Dearborn
StateProv:  MI
PostalCode: 48121-2053
Country:    US

NetRange: - 
NetName:    FORD-NETS
NetHandle:  NET-136-1-0-0-1
Parent:     NET-136-0-0-0-0
NetType:    Direct Assignment
NameServer: DNS004.FORD.COM
NameServer: DNS003.FORD.COM
RegDate:    1989-08-22
Updated:    1999-12-01

TechHandle: ZF4-ARIN
TechName:   Ford Motor Company 
TechPhone:  +1-313-390-7095
TechEmail:  dnsadmin@ford.com 

# ARIN WHOIS database, last updated 2004-02-27 19:15
# Enter ? for additional hints on searching ARIN's WHOIS database.
If you then look in ntop's p2c table, you find:
Mystery solved. ARIN allocated the block to a US company, so that's what ARIN lists the allocation as.

Could ntop do better - yes, but only with knowledge of the (non-public) internal division of Ford's address block. If you have that knowledge and it is important to you, then create a private p2c table. If you do a

make p2ctable

in the ntop source directory, you invoke the utils/p2c script, which downloads the raw data from the registries and builds a new p2c file. It also has the capability for adding 'manual' override information via files named manual.something. For example, if you created a file manual.ford:


and rebuild the p2c file, that breakdown of Ford's range would now be reflected in the country flags.

The manual file format is

name|countrycode|ipv4|address|number of addresses

Where name can be anything you want, countrycode must be 1, 2 or 3 characters and is used to create the IMG tag for the flag shown, i.e. xxx.gif, ipv4 is the constant 'ipv4', address is a numeric IP address and number of addresses is, well, the number of sequential addresses this applies to. Thus the line says that addresses from - are located in the UK. Check the rebuilt table and there it is:


Is that correct? Who knows. But it's a good example.

Another 'clever' thing you could do is to override ARIN's data with these lines:

(9175040 represents 140 * 256 * 256 which is the size of the Ford block)

Now if you create fmc.gif and fmk.gif - perhaps the Ford and Ford/UK flags, those are what will show up under 'domain'.

Tiny flags

There are plenty of sets of better/larger/more detailed flags. As long as they're named according to the ISO 3166 code (e.g. us.gif for USA), ntop will find and use them in the html/statsicons/ directory. See the note in docs/FAQ for a couple of available sets.