![]() |
![]() |
GTrace: A tool for the geographical visualization of Internet paths. |
![]() ![]() |
![]() |
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
![]() |
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.
![]() #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 '/':
![]()
![]() ![]() |
![]() |
||
for more information: info @ caida.org | last update: | |
this page: |