ArticlePDF Available

Abstract and Figures

Traceroute is the main tools to explore Internet path. It provides limited information about each node along the path. However, Traceroute cannot go further in statistics analysis, or \emph{Man-Machine Interface (MMI)}. Indeed, there are no graphical tool that is able to draw all paths used by IP routes. We present a new tool that can handle more than 1,000 Traceroute results, map them, identify graphically MPLS links, get information of usage of all routes (in percent) to improve the knowledge between countries' links. rTraceroute want to go deeper in usage of atomic traces. In this paper, we will discuss the concept of rTraceroute and present some example of usage.
Content may be subject to copyright.
arXiv:1703.05903v1 [cs.NI] 17 Mar 2017
rTraceroute: Réunion Traceroute Visualization
Xavier Nicolay, Réhan Noordallyand Yassine Gangat∗†
Laboratoire d’Informatique et de Mathématiques
Laboratoire d’Energétique, d’Electronique et Procédés
University of Reunion Island, 15 Rue René Cassin, 97490 Sainte Clotilde, France
email: firstname.lastname@univ-reunion.fr
Abstract—Traceroute is the main tools to explore Internet path.
It provides limited information about each node along the path.
However, Traceroute cannot go further in statistics analysis, or
Man-Machine Interface (MMI).
Indeed, there are no graphical tool that is able to draw all paths
used by IP routes. We present a new tool that can handle more
than 1,000 Traceroute results, map them, identify graphically
MPLS links, get information of usage of all routes (in percent)
to improve the knowledge between countries’ links. rTraceroute
want to go deeper in usage of atomic traces. In this paper, we will
discuss the concept of rTraceroute and present some example of
usage.
I. INTRO DUC TI ON
A. Context
Since the beginning of the Internet, the network has evolved
from a simple graph with few vertices to a wide and a complex
graph with uncountable number of nodes.
To improve our understanding of the Internet routing and
its topology, active metrology is the only way possible with
the injection of packets in the network. Traceroute is one of
the most widely used network measurement tools. It reports
an IP address for each network-layer device along the path
from a source to a destination host in an IP network. Network
operators and researchers rely on Traceroute to diagnose
network problems and to infer properties of IP networks, such
as the topology of the Internet.
Reunion Island is a small territory located in the Indian
Ocean, near South Africa, off the eastern coast of Madagascar.
However it is also one of the overseas departments of France.
For Reunion Island, this issue is more important than other
places due to its particular connectivity to the Internet based
on two submarine cables, called South Africa Far-East (SAFE)
and Lower Indian Ocean Network (LION) II, respectively in
green and in red in figure 1. If in one way, we know the
physical path of the Internet connection, in the other way, no
one knows the logical path of our connection. This is why
we want to graph the links between Reunion Island and the
world-wide destination. This new representation will improve
the global knowledge of the local topology.
B. Project
The council of Region Reunion have financed a metrology
project, with European Regional Development Funds (ERDF)
to identify the difficulties of the Reunion Island connectivity.
The requirements for this project are:
Fig. 1. Mascarene islands submarine cable - Source:
www.submarinecablemap.com
1) To identify the first hop after any connection leave
Reunion Island and the last hop before it reaches us. This
will help on the characterization of the logical exits and
entries for Reunion Island.
2) To detect the MultiProtocol Label Switch (MPLS) link
between Reunion Island and the different hops. It will
help to understand how are the exits and entries for
Reunion Island.
3) To focus on the regional peering problem. This item will
allow us to see if the physical cable and the routing
policies could be superposed.
4) To identify the most encountered node after (resp. before)
leaving (resp. reaching) Reunion Island. This could im-
prove our knowledge of the routing rules of all Internet
Service Providers (ISP) present on the territory.
5) To measure the minimal delay associated with each links
between Reunion Island and the next (resp. previous) hop.
It could detect prioritized link based on the final (resp.
original) destination (resp. source).
However identifying these points are not easily obtained with
small data-set. We need to analyze quite big data-set, more
than one probe for each ISP present on the Island. Usually,
each network tool generates its own measurements before
creating an output in text and/or image format. It is difficult
to combine data from several sources (resp. destination) from
(resp. to) a same country without a platform measurement.
Moreover, before running an analysis we need to proceed
methodically as follows:
1) Cleaning data-sets.
2) Matching data-sets from different tools, with different
standards.
3) Adding Geo-localization.
4) Showing result on a map.
To help solve this problem, we propose rTraceroute, a tool
which is "easy to use" but can provide a map together with
statistics by analyzing data from different Traceroute sources.
This tool take only one parameter: a folder which contains data
from Traceroute tools. It gives us then two output: the first one
is a statistic file about each node meet and the second is a map
with the different link between countries.
Thus, rTraceroute allows us to save time and to focus on
the analyzing of outputs. The rest of this paper is organized as
follows. At first, we will describe the some existing tools in
section II. The section III describes rTraceroute. An example
of how it works is presented in IV and it will be followed by
a conclusion in section V.
II. EXI ST ING T OO L S
As things stand today, no tool is available to fill our needs.
However, we can find some tools that could answer some of
them. Indeed, there are tools for the identification of the path
from a probe to a destination. This is the reason why we have
created rTraceroute to fill the need from this project.
In this section, we will present several tools that could help
us. We have categorized them as follows:
1) Tools that give raw results, without any statistics or map.
2) Platforms measurement that can take advantage of the
previous tools and use them together.
3) Mapping tools that can draw their result on a map.
A. Raw Results
These tools would provide us data from one measurement,
but they have not been built to generate a large raw data
without a script.
1) Traceroute: Traceroute [1] is the most popular tool
to measure path length and to determine the routes that
packets follow from a source node to a destination node.
With the growth of the Internet, many paths can be found
with Traceroute. But the main flaw of this tool is that it could
only generate raw data (without any statistic or mapping).
2) Paris-Traceroute: Paris-Traceroute [2] is a Traceroute-
like tool, but it is less sensitive to the load-balancing
phenomena. The output of this tool announces some errors
in the paths, like Unreachable Network (!N) or Unreachable
Host (!H). The using of explicit MultiProtocol Label Switch
(MPLS) [3] link is also provided by the tool. Using Paris-
Traceroute in our work could only identify the MPLS link
but it has the same flaws as Traceroute.
3) TraIXceroute: TraIXceroute [4] is also a Traceroute-
like tool with the discovering of Internet eXchange Point
(IXP) in the paths. This version of Traceroute combines two
databases, PeeringDB [5] and Packet Clearing House [6], for
the identification of these particular nodes. This information
could help for the reconstruction of the country crossed.
Despite an accuracy of 92-93%, this tool is not adapted for our
study because it can only detect the regional routing problem
with the IXP databases [4].
4) Reverse-Traceroute: Asymetric path is frequent in the
Internet, and it’s very difficult to identify the reverse path.
To avoid this, [7] has presented Reverse-Traceroute. This tool
aims to identify the return path of a classic Traceroute, with
an accuracy of 87% for hops identification. It’s mainly based
on two IP options, IP Record-Route and IP Timestamp op-
tion. Like the original Traceroute, reverse-Traceroute can only
generate Traceroute raw data but for the return way. Another
method to obtain the reverse path is using a measurement
platform.
B. Measurement Platform
According to [8], an Internet measurement platform is
an infrastructure of dedicated probes that periodically run
network measurement tests on the Internet.
1) Atlas RIPE NCC: Atlas RIPE NCC [9] is an active
measurement platform, which allowed to use several active
tools, like ping, DNS, HTTP or NTP for example. There
are two different tools for path measurement. The default
one is Paris-Traceroute. The second one is the original
Traceroute. Atlas platform return the results in JavaScript
Object Notation (JSON) format. It is possible also to map the
path with OpenIPMap [10]. Despite the fact Atlas could use
Paris-Traceroute, made mapping with geo-localization and
compare large data produced by its measurement, this platform
is not adapted to our project because it lacks the statistics part.
2) Planet-Lab: In 2003, some American researchers
deployed a test-bed platform called Planet-Lab [11]. In 2008,
a European portion of Planet-Lab [12] have been created. On
Planet-Lab nodes, researchers can install the tool they need
for their works. With this politic, this platform could combine
several tools. Nevertheless, it is unable to identify the last
(resp. first) hop after (resp. before) reaching (resp. leaving)
Reunion Island. Moreover, the management of large data is
not allowed on PlanetLab.
3) Archipelago: Center for Applied Internet Data Analysis
(CAIDA) has deployed its own platform in 2007, called
Archipelago [13]. The probe connected to this platform al-
lows us to make five main measurements, including ping
and Traceroute. But Archipelago, as Traceroute, could only
generate raw data without any analysis.
C. Mapped results
1) GTrace: The first tool created to graph Traceroute data
was GTrace [14]. This tool generates its own Traceroute data
and draw it on a map. It works with city name abbreviations
or airport codes, lookup client and two IP databases to validate
each IP addresses location. This tool was not maintained for
a long time and doesn’t support the x86 architecture. Due to
this, we were unable to test it.
2) Topology Visualization Tool: In [15], a tool centralized
on analysis topology in Africa was presented. This tool can
generate its own Traceroute measurement and graph it after
requesting information about nodes from several databases.
The design is largely based on existing visualization tools,
such as OpenIPMap project, and focuses only on the African
continent. The source code of the tool was not indicated in
the article, thus no test has been made.
The table I resumes the possibilities of each tool presented
previously. The cells in gray represent the available options
for each tool, when the white cells mean that the option is not
present.
The header line of the table show our needs:
The identification of the last hop corresponds to the
country where the node is hosted before leaving (resp.
joining) a specific country. Only a graph tool can identify
this point.
MPLS mark detect the explicit MPLS link between two
nodes. Only Paris-Traceroute can detect these, when our
rTraceroute with the graph part can detect invisible MPLS
route.
Statistics part needs a large amount of data for the
analyze. In general, the raw results generator does not
provide any analysis. Even graphic tools can’t do it be-
cause it redraws on the map on each new test. rTraceroute
can analyze a large dataset and make some statistics one
each meeting node.
The geo-localization of each IP address is based on the
declaration of the RIR plus the ISP. It’s well known that
the Geo-localization is not accurate science. rTraceroute
propose a database which could be improved by the user
analysis.
In the general case, mapping tools need to generate their
own data before draw them on a map. The first problem
concerns the choice of the map and the possibility to
download the final result. With rTraceroute, you can
choose your own map as input and download the results
for any publication or presentation. Mapping data allows
us to identify the different countries pass through and
detect the potential errors. With rTraceroute, these phe-
nomena could be easily detected by the mapping and the
statistics part.
The database is mainly used for Geo-localization of IP
address or detection of the IXP. Our database is, for now,
focus on Reunion Island with the help of delay analysis.
The regional routing problem means the identifica-
tion of peering mistakes, like boomerang-routing phe-
nomenon [16].
Each tool provide to generate its own raw data one by
one. rTraceroute propose to analyze a large dataset for
the statistics and mapping part.
Due to the imperfections of these tools (relatively to our
need), we have made the choice to develop a new tool:
rTraceroute.
III. RTRAC EROU TE
A. The concept
rTraceroute have been created to simplify the Traceroute
data file analysis.
On the one hand, we must process a huge number (more
than 1 million) of Traceroute files. On the other hand, we
are looking for performance. The choice to handle this is
to write the program with standard C, keeping in mind
that it should be compatible (Linux, OS X, ...), without any
platform-specific code. We also want the program to be easy
to compile (this is why the code is a monolithic bloc, for
less than three thousand lines), with a very simple Makefile.
Today, the executable run on a dedicated server with Linux
Ubuntu 14.0.4 LTS.
The figure 2 schematize the concept of rTraceroute. The
inputs used by rTraceroute are :
Several files of Traceroute data, whether it comes from
Paris-Traceroute [2] or Atlas platform [9], in text format.
The URI of the database used for geo-localization.
A Map.
Then, rTraceroute will proceed as follows:
1) Parsing and Cleaning: As the input data from Paris-
Traceroute [2] or Atlas platform [9] are text files, the
program must parse JSON files as well as plain text
files. The parse procedure for JSON files is made with
NXJson [17]. To be more efficient, the program has a
"cleaning procedure" (as it has been explained in I-B
) that eliminates useless (or corrupted) files. The pre-
parsing subroutine uses the following exclusion pattern:
JSON corrupted.
JSON file contains 3 last RTT as 0(zero) [unreach-
able].
Traceroute corrupted [file contains more than one
Traceroute].
Traceroute contains 3 stars on the last hop [host
unreachable].
Traceroute contains !H or !N or WARN string [unreach-
able].
2) Statistics: During parsing files, rTraceroute create an
internal linked-chain memorizing all information. Each IP
address and hop are marked with an on the fly calculated
RTT; later completed with the localization (country) from
the MySQL internal database.
3) Geo-localization: From this step, we need to geo-localize
IP address. This is why the program needs a MySQL
database (connection information is "hard-coded" in
main.h). . Two tables are used: the first one to geo-localize
IP address and the second one to place the country on a
map.
Then, to be able to draw each trace, gdlib has been used.
To store all information obtained during the process, three
kinds of tuples are used:
{hop, ip address, rtt, occurrences} is
added when reading files.
{mapx1, mapy1, mapx2, mapy2,
ip_address1, ip_address2, link} is
created when drawing is done, to handle all MPLS
links.
TABLE I
TOO LS O P TI O N AVAI LA BI LITY
Need
Tools Last Hop identification MPLS Mark Statistics Geo-localization Mapping Database Regional Routing problem Large data
Traceroute
Paris-Traceroute YES
TraIXroute YES YES
Reverse-Traceroute
Atlas RIPE NCC YES YES YES YES YES YES
PlanetLab YES YES YES YES
Archipelago
Gtrace YES YES YES YES
African Visual Route YES YES YES YES
rTraceroute YES YES YES YES YES YES YES YES
Fig. 2. Concept of rTraceroute
{xdeb, ydeb, xfin, yfin, occurences,
rtt, mpls} is also handled when the program
draws.
4) MPLS Detection:Paris-Traceroute can detect explicit
MPLS links and marked them in its raw data. When
rTraceroute find the marks, it memorized the link to plot
them in a different coloring at the end of the mapping.
5) Mapping: Some useful options have been implemented
as the program can handle html color’s name and create
statistics:
It can draw only the last links (the last hop before
coming in one country).
It can make the thickness of the link proportional of
its use (with the -redraw option).
It colorize MPLS links.
The program produces three result files:
A simple one that contains only 5 columns:
hop_position, IP address, occurrence,
average_delay, country, used for a later
statistical purpose.
A very verbose one called trace.txt that explicitly
details all internal operations. From this text file, it is
possible to extract and produce more results (as statistics
in percent of use’s link). for examples:
to extract all MPLS links:
$ grep ’lien.*MPLS’ trace.txt
and we obtain this kind of result:
// lien <-> MPLS: 93.17.132.110
109.24.74.178
to find information on each drawing line (x1,y1 to
x2,y2), occurrences, occurrence in percent between all
lines, minimal time, geo-localization, in text, for all
segments:
grep ’__ trajet’ trace.txt
and we obtain this kind of result:
__ trajet: 3626 1638 -> 2581 1582:
105 (2.81%) [AU - RE et temps min
505.39 (2.81%)]
Two graphical files (maps): all segments of the input files
on the first one and only the segments of the last hop for
a destination point (x,y) on the last map.
rTraceroute is the most adapted tool for our project. Indeed,
its capacity of mapping help us to answer the first need of
the project, which is the identification of the first (resp. lat)
hop after (resp. before) leave (resp. reach) Reunion Island.
The map function also help us on the third item of the
project: the regional peering problem. Paris-Traceroute allow
to detect explicit MPLS link. With rTraceroute, even the
invisible MPLS [3] link is shown with the maps option. The
statistics part of rTraceroute permits to answer the last two
points, which are respectively the identification of the most
encountered node after (resp. before) leaving (resp. reaching)
Reunion Island and the minimal delay associated with each
links between Reunion Island and the next (resp. previous)
hop.
IV. APP L IC ATI ON O F RTRACE ROUT E O N REUN ION IS LA N D
This paper has begun with a quick presentation of different
active tools or platforms. This part will show how rTraceroute
used the data provided by these tools for analysis path from
a country to several destinations. The section IV-A explain
how rTraceroute can be used with direct Paris-Traceroute data,
when IV-B used Paris-Traceroute JSON formatted from Atlas
RIPE NCC platform as data. The results have been previously
analyzed in [18] and are available on the website of the
authors.
A. Paris-Traceroute dataset
In this example, we will test rTraceroute on the data-set
publicly available and coming from [18]. This large data was
obtained during one month, between third of July and third of
August 2016. With 27 Raspberry Pi[19] used as measurement
probes, each day we have tried to reach 10,000 IPv4 spread
around the world as destination. At the end of the measurement
campaign we have obtained a total of 6,458,025 raw traces.
Combined with rTraceroute, the raw data have been reduced
to 1,015,180 available for path analysis. The using of rTracer-
oute on Paris-Traceroute data have these advantages:
The first one concern the raw data. The tools can filter
only the data which fill the selection criteria presented in
the section III
Mapping the path makes the path analysis between coun-
tries easier. Along with mapping, it is possible to print
only the first (resp. last) node before (resp. after) leaving
(resp. reaching) a country with the path and the delay
associated.
Lastly, rTraceroute can change all explicit MPLS link’s
color found by Paris-Traceroute. The mapping would
permit the detection of invisible MPLS links.
The map 3 represent the results for the first hop when data
leave Reunion Island.
In this figure, we can see the first hop after Reunion Island.
Despite the presence of two physical connections with Asia
and Africa 1, we can notice that most of the first hops are not
connected to these continents but to Europe.
Another interesting point is the presence of a direct link
between Reunion and USA, sign of invisible MPLS link. We
can also see that more of 96% of our data going through
France before joining the destination, even if the destination
is close to Reunion Island. A detailed analysis of the results
are available in [18].
The analysis of the same data with only a BASH script has
taken more than one day. With rTraceroute, around 10 minutes
is sufficient.
B. Atlas RIPE NCC dataset
In this case study, we would analysis 300,000 measurement
towards Reunion Island from all world. Our trace includes
measurement performed from the third of July to the third of
August 2016. 1,000 atlas probes would reach ten Raspberry
Pi [20] deployed over Reunion Island. The atlas probe was
selected with the same distribution as the IPv4 addresses for
the Paris-Traceroute case.
Without rTraceroute, we would have been constraint by using
OpenIPMap [10]. The tools present some limits: it requires
to add manually the other path measurements to compare the
results and the maps can’t be downloaded. The "cleaning step"
of rTraceroute have reduced our data to 38,714 traces. The
advantage of combine rTraceroute with Atlas is the same as
with the other Traceroute tools. But in this context, we can
highlight three benefits:
First we can easily combine data from several Atlas math
measurements for the analysis. A script could download
the JSON file and add it in a folder which could also be
analyzed by rTraceroute.
The maps are hosted on the system which run rTracer-
oute. Maps can be downloaded and used after.
Eventually, the statistics file created by rTraceroute is
very important. Each line of the file contains the position
of an IP address meet during the measurement, the IP
address, the occurrence of this couple, the meaning delay
and the country associated with the IP address.
The map 4 is an example of all path existing to join Reunion
Island using Atlas and rTraceroute. On the figure 4, we can
see a direct link between Paraguay and Reunion Island without
a submarine cable existing. This proves us that an invisible
MPLS link exists. Without rTraceroute, this analysis will be
more difficult to be found. We can also notice the use of the
section of the submarine cable from Asia and Africa. The
percentage of using the exit point for submarine cable in the
two continent is less than 0.5%, when more than 99% going
through France, with a minimal delay of 183.30ms.
This campaign of measurement from the world towards Re-
union Island has provided 300,000 JSON raw data for a
time analysis of 3 minutes with rTraceroute. A BASH script
developed for the analysis of these raw data has taken more
than half a day.
Fig. 3. Paris-Traceroute results example
Fig. 4. Example of results from rTraceroute used in combination with Atlas
V. CO NC LUS IO N
Studying the Internet connectivity of Reunion Island is im-
portant for the economic development of the island. An ERDF
project has been funded to identify the difficulties of the
Internet connectivity of the Island. Several tools are available,
but none of them could cover our needs. Nearly no tools
can handle a large number of Traceroute-files and draw all
the path on a map. This why we have implemented a new
tool, called rTraceroute. It also offers us a new approach to
observe the Internet topology with a different point of view.
As for today, there is no IP geo-localization database reliable
enough to plot every IP found in the traces. The next step
will be to improve IP geo-localization of each point, based
on delay between to point and a system of triangulation. IPv6
deployment is in its infancy: the routes could not be optimized.
Adding IPv6 in rTraceroute could also help the deployment
of this new protocol in the area, but some adaptations need
to be done for IPv6 because the actual work is based on
IPv4. Exportation of maps in Encapsulated PostScript (EPS)
or Scalable Vector Graphic (SVG) format is also planned in
the future (actually, the maps result are only in PNG format).
REF ERE NC ES
[1] G. S. Malkin, “Traceroute using an IP option,” 1993.
[2] B. Augustin, X. Cuvellier, B. Orgogozo, F. Viger, T. Friedman, M. Lat-
apy, C. Magnien, and R. Teixeira, “Avoiding traceroute anomalies with
paris traceroute,” in Proceedings of the 6th ACM SIGCOMM conference
on Internet measurement. ACM, 2006, pp. 153–158.
[3] B. Donnet, M. Luckie, P. Mérindol, and J.-J. Pansiot, “Revealing
mpls tunnels obscured from traceroute,ACM SIGCOMM Computer
Communication Review, vol. 42, no. 2, pp. 87–93, 2012.
[4] G. Nomikos and X. Dimitropoulos, “traixroute: Detecting ixps in tracer-
oute paths,” in International Conference on Passive and Active Network
Measurement. Springer, 2016, pp. 346–358.
[5] P. DB, “Peeringdb facilitates the exchange of information related to
peering.” [Online]. Available: https://www.peeringdb.com/
[6] P. C. House, “Internet exchange directory,” 2014.
[7] E. Katz-Bassett, H. V. Madhyastha, V. K. Adhikari, C. Scott, J. Sherry,
P. Van Wesep, T. E. Anderson, and A. Krishnamurthy, “Reverse tracer-
oute.” in NSDI, vol. 10, 2010, pp. 219–234.
[8] V. Bajpai and J. Schönwälder, “A survey on internet performance
measurement platforms and related standardization efforts,IEEE Com-
munications Surveys & Tutorials, vol. 17, no. 3, pp. 1313–1341, 2015.
[9] R. NCC, “RIPE atlas,” 2010. [Online]. Available: https://atlas.ripe.net
[10] E. Aben, “Infrastructure geolocation -
plan of action,” 2015. [Online]. Available:
https://labs.ripe.net/Members/emileaben/infrastructure-geolocation- plan-of-action
[11] B. Chun, D. Culler, T. Roscoe, A. Bavier, L. Peterson,
M. Wawrzoniak, and M. Bowman, “PlanetLab: An overlay
testbed for broad-coverage services,SIGCOMM Comput. Commun.
Rev., vol. 33, no. 3, pp. 3–12, Jul. 2003. [Online]. Available:
http://doi.acm.org/10.1145/956993.956995
[12] “PlanetLab europe, an open platform for developing, deploying,
and accessing planetary-scale services.” [Online]. Available:
http://planet-lab.eu/
[13] K. Claffy, Y. Hyun, K. Keys, M. Fomenkov, and D. Krioukov, “Internet
mapping: from art to science,” in Conference For Homeland Security,
2009. CATCH’09. Cybersecurity Applications & Technology. IEEE,
2009, pp. 205–211.
[14] R. Periakaruppan, E. Nemeth et al., “GTrace: A graphical traceroute
tool.” in LISA, vol. 99, 1999, pp. 69–78.
[15] C. Yang, H. Suleman, and J. Chavula, “A topology visualisation tool for
national research and education networks in Africa,” in IST-Africa Week
Conference, 2016. IIMC, 2016, pp. 1–11.
[16] J. A. Obar and A. Clement, “Internet surveillance and boomerang
routing: A call for Canadian network sovereignty,” in TEM 2013: Pro-
ceedings of the Technology & Emerging Media Track-Annual Conference
of the Canadian Communication Association (Victoria), 2012.
[17] Y. Stavnichiy, “Nxjson, a light json parser written in c.” [Online].
Available: https://bitbucket.org/yarosla/nxjson/
[18] R. Noordally, X. Nicolay, P. Anelli, R. Lorion, and P. U. Tournoux,
“Analysis of internet latency : the reunion island case,” in Asian Internet
Engineering Conference. ACM, 2016, pp. 49–56.
[19] M. Maksimovi´
c, V. Vujovi´
c, N. Davidovi´
c, V. Miloševi´
c, and B. Per-
iši´
c, “Raspberry pi as internet of things hardware: performances and
constraints,design issues, vol. 3, p. 8, 2014.
[20] “Raspberry Pi, official website. [Online]. Available:
http://www.raspberrypi.org/
APP EN D IX
A version of rTraceroute is in public access at
http://lim.univ-reunion.fr/rTraceroute
... D. Our original tool : the rtraceroute As we want to handle more than 1 Million traces, we develop our tool [15] with C and threadpool. Maximum of parallelization are implemented and now the tool can parse about 4.5 Millions in about 1 hour on a computer with 8 Cores. ...
Conference Paper
Full-text available
Internet has become a foundation of our modern society. However, all regions or countries do not have the same Internet access regarding quality especially in the Indian Ocean Area (IOA). To improve this quality it is important to have a deep knowledge of the Internet physical and logical topology and associated performance. However, these knowledges are not shared by Internet service providers. In this paper, we describe a large scale measurement study in which we deploy probes in different IOA countries, we generate network traces, develop a tool to extract useful information and analyze these information. We show that most of the IOA traffic exits through one point even if there exists multiple exit points.
Conference Paper
Full-text available
Internet eXchange Points (IXP) are critical components of the Internet infrastructure that affect its performance, evolution, security and economics. In this work, we introduce techniques to augment the well-known traceroute tool with the capability of identifying if and where exactly IXPs are crossed in end-to-end paths. Knowing this information can help end-users have more transparency over how their traffic flows in the Internet. Our tool, called traIXroute, exploits data from the PeeringDB (PDB) and the Packet Clearing House (PCH) about IXP IP addresses of BGP routers, IXP members, and IXP prefixes. We show that the used data are both rich, i.e., we find 12,716 IP addresses of BGP routers in 460 IXPs, and mostly accurate, i.e., our validation shows 92-93% accuracy. In addition, 78.2% of the detected IXPs in our data are based on multiple diverse evidence and therefore help have higher confidence on the detected IXPs than when relying solely on IXP prefixes. To demonstrate the utility of our tool, we use it to show that one out of five paths in our data cross an IXP and that paths do not normally cross more than a single IXP, as it is expected based on the valley-free model about Internet policies. Furthermore, although the top IXPs both in terms of paths and members are located in Europe, US IXPs attract many more paths than their number of members indicates.
Article
Full-text available
Operators have deployed Multiprotocol Label Switching (MPLS) in the Internet for over a decade. However, its impact on Internet topology measurements is not well known, and it is possible for some MPLS configurations to lead to false router-level links in maps derived from traceroute data. In this paper, we introduce a measurement-based classification of MPLS tunnels, identifying tunnels where IP hops are revealed but not explicitly tagged as label switching routers, as well as tunnels that obscure the underlying path. Using a large-scale dataset we collected, we show that paths frequently cross MPLS tunnels in today's Internet: in our data, at least 30% of the paths we tested traverse an MPLS tunnel. We also propose and evaluate several methods to reveal MPLS tunnels that are not explicitly flagged as such: we discover that their fraction is significant (up to half the explicit tunnel quantity) but most of them do not obscure IP-level topology discovery.
Conference Paper
Full-text available
Traceroute is widely used, from the diagnosis of network problems to the assemblage of internet maps. However, there are a few serious problems with this tool, in particu- lar due to the presence of load balancing routers in the net- work. This paper describes a number of anomalies that arise in nearly all traceroute-based measurements. We categorize them as "loops", "cycles", and "diamonds". We provide a new publicly-available traceroute, called Paris traceroute, which controls packet header contents to obtain a more pre- cise picture of the actual routes that packets follow. This new tool allows us to find conclusive explanations for some of the anomalies, and to suggest possible causes for others. Categories and Subject Descriptors: C.2.3 (Computer
Conference Paper
Internet connectivity is not fairly distributed around the world, in particular for islands or isolated areas. An example, the internet connection of Reunion Island is mainly based on links to France located about 10,000kms away. This situation generated a particular connection which induced high delays and degraded internet service. Typically, the minimal delay between France and Reunion Island is around 180ms.In this paper, we investigate the performance of the Internet connection by analyzing delay and path properties from and to Reunion Island mapped to continent IPv4 spread. With two experiments, based on 27 local probes and 7,860,000 traces, we propose a correlation analyzing between delay and path properties. One particular finding is that the delay is more dependent of the chosen path as the geographical distance, compared to models in literature.
Conference Paper
Previous research on National Research and Education Networks (NRENs) in Africa has shown high latency in traffic exchanged between networks, with 75% of this traffic taking circuitous routes through Europe. This paper presents a user-centered creation of a geospatial visualisation tool that can be used to show the network structure of African NRENs, using Traceroute as a method for network topology discovery. The visualisation tool allows multiple Traceroutes for a single IP address to be viewed on a map from various vantage points. The tool's effectiveness and accuracy at communicating the logical network topology of African NRENs and routes of traffic traversal was assessed. Results from usability tests showed that the tool was able to effectively and accurately communicate the logical topology on a country and continental level with over 68% of visual queries having been answered successfully.
Article
A number of Internet measurement platforms have emerged in the last few years. These platforms have deployed thousands of probes at strategic locations within access and backbone networks and behind residential gateways. In this paper we provide a taxonomy of these measurement platforms on the basis of their deployment use-case. We describe these platforms in detail by exploring their coverage, scale, lifetime, deployed metrics and measurement tools, architecture and overall research impact. We conclude the survey by describing current standard- ization efforts to make large-scale performance measurement platforms interoperable.
Article
Preliminary analysis of more than 25,000 traceroutes reveals a phenomenon we call ‘boomerang routing’ whereby internet transmissions originating and terminating in Canada are routinely routed through the United States. Canadian originated transmissions that travel to a destination in Canada via a U.S. switching centre or carrier are subject to U.S. law - including the USA Patriot Act and FISAA. As a result, these transmissions expose Canadians to potential U.S. surveillance activities – a violation of Canadian network sovereignty.In the face of this unregulated surveillance of Canadians, the Federal government and internet service providers should re-assert our national network sovereignty and better protect Canadian civil liberties. In what follows, we present boomerang route findings and discuss U.S. National Security Agency (NSA) tracking concerns. We then offer a plan for strengthening Canadian network sovereignty, including: 1) strengthening and enforcement of Canadian privacy law (e.g. PIPEDA), and 2) repatriation of Canadian internet traffic by building more internet exchange points.
Article
We are designing, implementing, deploying, and oper-ating a secure measurement platform capable of perform-ing various types of Internet infrastructure measurements and assessments. We integrate state-of-the-art measure-ment and analysis capabilities to try to build a coherent view of Internet topology. In September 2007 we began to use this novel architecture to support ongoing global Inter-net topology measurement and mapping, and are now gath-ering the largest set of IP topology data for use by academic researchers. We are using the best available techniques for IP topology mapping, and are developing some new tech-niques, as well as supporting software for data analysis, topology generation, and interactive visualization of result-ing large annotated graphs. This paper presents our current results, next steps, and future goals.
Conference Paper
Traceroute (Jacobson88), originally written by Van Jacobson in 1988, has become a classic tool for determining the routes that packets take from a source host to a destination host. It does not provide any information regarding the physical location of each node along the route, which makes it difficult to effectively identify geographically circuitous unicast routing. Indeed, there are examples of paths between hosts just a few miles apart that cross the entire United States and back, phenomena not immediately evident from the textual output of traceroute. While such path information may not be of much interest to many end users, it can provide valuable insight to system administrators, network engineers, operators and analysts. We present a tool that depicts geographically the IP path information that traceroute provides, drawing the nodes on a world map according to their latitude/longitude coordinates.