You are here



Fastping, developed by ENST,  is a fast ICMP scanner for TopHat/TDMI, a dedicated measurement infrastructure running over PlanetLab. If you landed to this page following a URL found within an ICMP packet, this means that you have been a target of an academic experiment with the fastping software, that this page introduces.

"Fast" in fastping means that 50k hosts can be probed in about 5 seconds (a more detailed performance analysis is reported in the fastping documentation). Scalability of a single proble is obtained in user-space (as opposite to the zmap sofware that requires root privileges), with a non-blocking multi-thread design (that allows to significantly exceed nMap Scripting Engine performance, but of course not as much as zmap).

Additionally, leveraging the TopHat/TDMI infrastructure, fastping couples the ability to scan a large number of hosts during small time windows,  to the availability of a large number of spatially disperse probes -- up to 1000 PlanetLab/OneLab nodes, of which typically around 300 are available at any time. 

Fastping synoptic

These temporal and spatial scalability properties can be leveraged for instance, to understand Internet properties such as (but not limited to):

  • anycast detection  (when all probes target the same target  during the same window, but change target over time)
  • bufferbloat evaluation (when each probe tracks disjoint targets, but keep the same target continuously over time)
  • Internet census (when each probe tracks disjoint targets,  changing target over time)

Fastping already perform a fair amount of statistical pre-processesing, providing output at different granularities. Namely, from the most coarse to the most fine-grained:

  • (txt) experiment summary
  • (cvs) per-probe statistics summary (e.g., CDF of relevant metrics as RTT delay,  RTT variation, or TTL variation)
  • (cvs) per-probe per-host statistics (e.g.,  quantiles of relevant merics as RTT delay,  RTT variation, or TTL variation)
  • (cvs) raw measurement 

The above results can be stored locally at a probe (useful for testing/local use), or uploaded to an repository via FTP (useful to centralize data collection from a PlanetLab experiment).

Quick start:

Fastping is a python script and

  • can be used as a standalone shell tool (its usage is thus relatively simply explained by the manpage)
  • can be used as a TopHat/TDMI component (out of scope of this page)
  • can be queried as a mPlane probe (i.e., receive and parse mPlane specification)

Example of use of the tool as a standalone shell tool and as mPlane probe can be found in the software package ( and HOWTO.mplane in the main directory respectively) as well as in the fastping documentation 

New features supported by the mPlane project

Fastping was entirely developed during the mPlane project. So thanks, mPlane!

mPlane proxy interface

The mPlane Fastping interface offers the ability to specify the set of target IP address ranges.

  • (simplest form) each probe can be queried individually, i.e., specifying the target for each probe in mPlane terms, and will upload the results on the specified server
  • (work in progress) measurement specification can be addressed to a dedicated mPlane supervisor, handling the TopHat/TDMI  probes, that will  dispatch  measurement specification to all Fastping probes that registered to the supervisor
mPlane custom registry

To harness the full power of fastping, a number of parameters have clearly been defined in the mPlane registry. While most of the parameters are trivial, one is worth discussing at length.

To achieve efficient operation, it is imperative for fastping to receive compact specification of target addresses ranges. However, the current mPlane registry only support a destination.ipv4 type specifying a single target address -- which clearly clashes with the ability of probing at large scale.

To circumvent with this current mPlane limit, the fastmPlane implementation employs  a clever trick that is both compatible with the current mPlane specifications, and that will possibly be entirely supported by future releases -- since the necessity to specify list of primitive types will be possible shared among multiple components, and thus supported by mPlane.

The fastping custom registry specify thus a destinations.ipv4range type whereby the s implies that a plurality of IPv4 ranges, expressed as A.B.C.D/N are expected. Notice that since a single address can be expressed as a /32 range, this effectively means that it is possible to practicaly "mix" addresses and ranges, while maintaining plurality of a single type


Official version