Proposal: do multicast testing on TTM boxes

  • From: Gert Doering <
    >
  • Date: Mon, 10 Oct 2005 16:38:17 +0200
  • Cc: Gert Doering <
    >
  • Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=Wu7oAJE3Mv/nzv6fBZnbOegJr129GNjRmp21nbZ3HanAtPPsTmr3y0uXBn1szcWq ;

Hi Folks,

I've briefly discussed this with Henk, and I'd like to discuss it in
the mailing list, to see whether there is support for it.

The initial question was "how to monitor the multicast Internet?", and
the answer is *hard* - you can't easily do it from just within one
network, as you never have a proper full view of multicast packets
flowing "to" and "fro".

So what you want is 

 - multicast beacons, that send packets in regular intervals to 
   well-known multicast addresses (some beacons exist already)

 - multicast listeners, that monitor incoming beacon packets, and 
   complain if packets from given senders stop arriving

 - some high level monitoring infrastructure that can use the data from
   "lots of beacons and listeners" to figure out *where* the problem is
   (it *has* to be in *this* or *that* AS, or in between)

And while thinking about how to build something like this internal to
our network, I thought "this is something the RIPE TTM network could
do perfectly well" - lots of boxes already deployed, good contacts to
local universities to write evaluation software, etc.

What do you think?

Gert Doering
        -- hosting TT12, which was broken for 2 years or so, but will 
           be back to life "real soon now"
-- 
Total number of prefixes smaller than registry allocations:  81421

SpaceNet AG                    Mail: netmaster@localhost
Joseph-Dollinger-Bogen 14      Tel : +49-89-32356-0
D- 80807 Muenchen              Fax : +49-89-32356-234