The MRINFO project

The aim of this project is to get information on the Internet structure through the mrinfo tool.
This tool uses IGMP queries (see the latest dvmrp draft, T. Pusateri, draft-ietf-idmr-dvmrp-v3). to get information on interfaces and neighbors of a router running an IPv4 multicast routing protocol, usually PIM.
By recursively calling mrinfo on neighbors of already known routers, one can map a subset of the mbone.
Although this is only a small subset of the Internet (and in fact a subset of the mbone due to filtering on some routers) we can get precise informations on the neighborhood of a router (number and status of interfaces, number of neighboring routers through the same interface and so on).
Currently about 10 000 routers can be queried by this method. Since this query is rather lightweight, we developped a script that collects data on the mbone everyday. this way we can obtain information on the local evolution of routers (frequency of configuration changes for example).
A preliminary paper (published in Annals of Telecommunications) can be found with a first analysis :

Local and Dynamic Analysis of Internet Multicast Router Topology, J.-J. PANSIOT, Annals of telecommunications, Vol. 62, Num. 3-4, pp 408--425 - march 2007

See also :
Quantifying ASes Multiconnectivity using Multicast Information, P. MÉRINDOL, V. VAN DER SCHRIECK, B. DONNET, O. BONAVENTURE, J.-J. PANSIOT ACM Internet Measurement Conference, ACM press, pp 370-376 - november 2009

Extracting Intra-Domain Topology from mrinfo Probing, J.-J. PANSIOT, P. MÉRINDOL, B. DONNET, O. BONAVENTURE, ACM Passive and Active Measurement Conference (PAM), Zurich, Springer, LNCS, pp 81-90, Vol. 6032, A. Kishnamurthy and B. Plattner - april 2010

DATA SETS

Data sets from daily collects can be found here.
There is a directory YYYY-MM for each month since may 2004, with a sub directory YYYY-MM-DD for each day of the month.
For a given day, the following files are available:

Summary.txt                           A summary of the collect indicating if this collect completed or not (due to some failure), and some global statistics
collect-YYYY-MM-DD.gz     A gzipped text file containing raw output from mrinfo (around 1MB)
ping_to_nonresponder.gz     A gzipped text file with the result of ping to routers not responding to mrinfo
ping_to_responder.gz             A gzipped text file with the result of ping to routers responding to mrinfo (only since 2005-12-06)

Warning : these files are raw files. For example, some routers may appear twice.

LOG

2008/11/01 Warning: since november 1st 2008, due to some changes in the configuration of the ISP routers, the number of collected routers has been strongly reduced: less than 100 routers from 2008/11/01 to 2009/06/13.

2009/06/13 The tool has been launched again with a new seed on 2009/06/13, collecting about 3000 routers daily

2010/04/09 The tool has been launched again with a new seed on 2010/04/09, and a new way to caculate the seed: now it is the set of responding routers on the last 30 days

2010/04/14 Found a bug in the mrinfo command: For routers with a large number of interfaces and/or neighbors, the mrinfo reply may become quite big.
For each local address (= interface) there is a block of 12 bytes (if there is at most one neighbor for this interface),
plus 4(n-1) bytes if there are n neighbors through this interface (switch connecting n+1 routers)
In addition there is the IP header (20 bytes) and the IGMP header (8 bytes).
1) Case of Juniper routers: they build a single big IP packet that is fragmented by the sending interface
    Since 122 interfaces give a packet of size 20 + 8 + 122*12 = 1492, more than 123 interfaces (or even less if there are switches)
will give rise to fragmentation.
    Example: router 130.79.20.13 has a fragmented output
    PROBLEM: in some cases (at least on a BSD host), fragments are not correctly reassembled by mrinfo, and the corresponding router is "lost". This bug does not show up on mrinfo for MacOSX (probably more an OS bug than a mrinfo bug?)
    NOTE: it seems that Juniper behaviour is not correct according to draft-ietf-idmr-dvmrp-v3-11(mrinfo messages are described in the dvmrpv3 draft):
```
The maximum packet length of any DVMRP message should be the maximum
   packet size required to be forwarded without fragmenting.  The use of
   Path MTU Discovery [Mogu90] is encouraged to determine this size.  In
   the absence of Path MTU, the Requirements for Internet Hosts [Brad89]
   specifies this number as 576 octets.
```
2) Case of cisco routers
    When the reply is too big, cisco routers build several packets, according to the draft above. Since 45 interfaces take
    20 + 8 + 45 * 12 = 568 bytes, routers with more than 45 interfaces (or less interfaces if there are switches) generate several IGMP packets.
    Example: router 151.6.105.106 or 213.254.0.69 have multipacket replies
    PROBLEM: There is no "continuation flag" in these messages, and BSD (and MacOSX) implementation do not wait for additional replies
    Consequence : all big cisco routers are truncated at 45 or less interfaces (note that this bug does not show up if mrinfo is executed on a cisco router, one could launch the script from a router :-))

COMMENT: looking back at our datasets, the consequences are that the "real" degree distribution is more heavy tailed than observed since Junipers with more than 122 interfaces and cisco with more than 45 are not correctly mapped. Also this explain why most "big routers" are Juniper in our dataset.

CONTACT

Jean-Jacques Pansiot, ICube, Université de Strasbourg, France
pansiot at unistra.fr

Last change on March 21 2013