About the Multicast Routing Report

----------------------------------------------------------

What this data represents

This data represents Mbone routes and their corresponding metrics as seen locally by this site. The data is collected using the route monitor package, which listens to DVMRP route updates issued by local routers. Using these updates, the route monitor creates a multicast routing table that reflects this sites view of the MBone. Changes to the routing table are reported (a change in the route/metric to a source is called a flap) on these web pages. The information shown here should reflect an accurate picture of the Mbone topology, as seen from this site.

huh, what does that mean??

The main quantity of interest is the stability of the routes. If a route changes, this should be reflected by a metric change. During a report period, the number of metric changes (i.e. flaps) for each route is recorded. Some routes should change due to link failures, but the majority should remain stable. The largest possible route has metric of 31, a metric of 32 implies the route is unreachable. A metric greater than 32 implies a poison reverse route.

How this data is collected

The data is collected by monitoring Mbone route updates exchanged by multicast routers at this site. Mbone routers multicast periodic routing messages. These multicasts are observed and recorded by the route monitor package running at this site. Every hour, the route monitor outputs routing statistics, resets all measures back to zero, and starts observing mcast routing packets again.

MBone Topology where this data is collected

FOOTOPOLOGY

How to Obtain This Data for Your Site

The route monitor package was developed at Xerox PARC by Daniel Massey and Bill Fenner. The route monitor package is freely available. It includes software to collect multicast route data, automatically generate these web pages, and provides CGI search scripts. The route monitor can be installed on most platforms that support Perl. A typical installation only requires editing a configuration file and running the install program. To obtain a copy of the route monitor package, go to the RouteMonitor Home Page .

Disclaimer that this says nothing bad about anyone in particular

The data reported here only reflects the view of Mbone as seen by this local site. If a route is listed as unreachable or appears to have flapped many times, this does not indicate a problem with the individual source for that route. A route may be unstable because of problems at the source OR ANYWHERE BETWEEN THIS SITE AND THE SOURCE. An unstable route does not demonstrate that site, that site's vendors, that site's service provider, or anything else associated with that site is necessarily wrong. An unstable route only indicates a problem somewhere between this site and the source. ----------------------------------------------------------

Huh???

Multicast routers must have some topology information about the Mbone. The topology information is used by mcast routing protocols such as PIM or DVMRP to perform operations such as RPF checks and is essential to the correct operation of any mcast routing protocol.

Because the Mbone topology is not identical to that of the unicast topology, mcast routers must have a mechanism to learn the relevant topology information and adjust this information when events such as link failures occur. The mechanism for doing this based on the Bellman Ford algorithm for finding shortest paths. This same method is also used by the unicast protocol RIP.

The algorithm works (simplified view) as follows. A router R1 keeps a table of its distance to each source and periodically sends this table to all its neighbors. Upon receiving a table from neighbor R2, R1 tries to determine which routes should have R2 as their first hop. To do this, R1 compares its distance to a source with the distance to R2 + R2's distance to the source. If the route via R2 is shorter, R1 declares R2 to be the first hop on the path to the source and adjusts it table accordingly.

It has been shown that (in the absence of zero length cycles), this process will eventually produce the correct shortest distances for each source at each router. A more complete description can be found in any algorithm's text or in the RFC for DVMRP or RIP. The data shown on this page is essentially the routing table computed by the route monitor at this site.

okay, back to where we were...