To execute a trace, specify the destination host/url, and press the ENTER key. You will see the traditional traceroute output in the lower section of the display with the locations being determined for each hop. These are drawn on the map as and when they are determined. The diagram below highlights the features of the GUI. You can also adjust the width of the table columns as well as move them around to your liking.

Once the trace is complete and the locations have been determined, the location verifier will attempt to determine which locations were unreasonable. You will see the RTTs of some hops being reestimated using ping and these changing color to green. Locations of hops with bad RTTs, not used in the verfication process are made red in color. You can disable the verifier from the options menu. Locations of nodes considered unresonable are disabled and not plotted, you can enable them if you like. Click on the disabled locations to read about why the verifier thought it was wrong and where it could possibly be.

Files describing properties of each domain are used to extract geographical hints embedded in hostnames. These files define parsing rules using Perl compatible regular expressions. If you happen to consistently see a set of hosts belonging to a domain, that have geographical hints in them, add a domain parsing file to determine the location of those set of nodes. Please post this to the mailing list so that others can also add it. If you modify or update any existing file please do the same.

For example, ALTER.NET (a domain name used by UUNET, a part of MCI/WorldCom) names some of their router interfaces with three letter airport codes as shown below:

s/.*?\.([^\.]+)\d\.ALTER\.NET/$1/this,airport.db
scl=santaclara,ca,us
tco=tysonscorner,va,us
nol=neworleans,la,us

The bold listing above shows an example of a GTrace domain parsing file that would work for ALTER.NET hosts. The file first defines the regular expressions, followed by any domain specific exceptions. The exceptions are strings that match the result of the regular expressions. The user may identify the exception's location either by city or by latitude/longitude value using the format shown below:

exception=city,state,country
                city,country
                L:latitude,longitude

In the former case, the user should also check to ensure that the cities database has a latitude/longitude entry for the city specified. The first line defines a substitution operation, which when matched against 193.ATM8-0-0.GW2.EWR1.ALTER.NET, would return EWR. The contents following the last '/' of the first line indicate what to do with a successful match, namely in this case to instruct the program to first check for a match in the data specified in the current file and then for a match in the airport database.

The reason for checking the domain parsing file first is that sometimes the naming scheme for a given domain is not consistent. For example, a search for SCL obtained from 198.ATM6-0.XR2.SCL1.ALTER.NET in the airport database would return a location for Santiago de Chile. In the case of ALTER.NET, they also use three letter codes that are not airport codes but abbreviations for US cities. Note that if this exception list were not present and SCL did get mapped to Chile, the Location Verifier would likely have eliminated it using the Round Trip Time (RTT) heuristic, which would have recognized the RTT as much too small to get a packet to Chile and back.

Steps to add a domain parsing file:

1. Use the following skeleton always!, its best you just copy an existing example and modify it. These files are located in the dpfs directory in the GTrace tree. For eg. if your adding a file for domain foobar.net, then you will name your file foobarnet without the period, and if your adding a file for an international top level domain for eg. foobar.net.de, then the name of your file should be foobarnetde

---

#Regular Expressions
(add the list of regular expressions here)

#Data --- Do Not Remove this line
(add the domain exceptions here)

---

2. There is a java program called regexTest in the dpfs directory that you can use to check if your regex is correct and extracting what you want. Here is an example:

lib6:dpfs $ java regexTest 's/.*?\.(.*?)\.cw\.net/$1' barak.bloomington.cw.net
Result : bloomington

If you get a java.lang.NoClassDefFoundError: caida/GTrace/Util, then set your CLASSPATH variable as follows:
setenv CLASSPATH <Path to where GTrace is located>/GTrace:$CLASSPATH

Once you've got the right regex then add this to the file, followed by a '/' and then informing the tool what you want to do with a successful match. You can specify more that one option by a comma separated list. So if you want to just always look up the match in the cities datbase you would add:

---

#Regular Expressions
s/.*?\.(.*?)\.cw\.net/$1/cities.db

#Data --- Do Not Remove this line

---

As an extension lets suppose you had an exception list, and you also wanted to lookup it up in another database called xyz.db that you added, you would add in order of preference:

---

#Regular Expressions
s/.*?\.(.*?)\.cw\.net/$1/this,cities.db,xyz.db

#Data --- Do Not Remove this line
sf=san$francisco,ca,us

---

You can specify any of the following as a comma separated list after the last '/':

• Any of the databases/textfiles available in the db directory
• this to indicate to lookup in the current file's exception list
• country to indicate to search for a two character country code

3. After you've made changes to the domain-parsing file, restart the application, delete the cache from the tools menu, (you must delete the cache or if the location for that host has already been determined from a previous trace, it will be taken from the cache) and check now to see that the location is being determined from a domain parsing file ( a blue ball next to the location).