All things related to multicast

[Debbie Fligor <>]

I'll miss the unicast updates to the server. Unless there's some other 
out-of-band way of reporting that you're trying to run dbeacon, if multicast 
isn't working for a site you can't tell it is there.

that said, I agree that dbeacon is easier to keep running, but even it's no 
longer under development.  how much interest is there really in doing this?  
I offered to donate a group address for this a couple of years ago, but 
someone (Caren?) said to wait they were about to spin something up. 

we run 2 different dbeacon groups, one for our campus and one for our 
regional net to see our local connectivity.  We have one host on each network 
participate in the other for reachability testing.  having one host from each 
also participating in a global group should be fairly easy to build.  There 
is no central server that needs to be built for dbeacon, all we need to do is 
agree on a group to use.

I can allocate a group for this out of our 233. or 234. space if that would 
help get it started.


-----
-debbie
Debbie Fligor, n9dn       Network Engineer, CITES, Univ. of Il
email: 

          <http://www.uiuc.edu/ph/www/fligor>
                   "My turn."  -River Tam





On May 19, 2011, at 9:50, Zenon Mousmoulas wrote:

> I think it's about time the legacy mbeacon was shutdown and replaced by 
> dbeacon, where all participating beacons would also be running the 
> reporting CGI script (and providing public access to it), so that we can 
> finally see the full picture about international multicast connectivity and 
> eliminate the reporting SPoF.

> 
> I would also take this opportunity to suggest that the number of 
> participating beacons be voluntarily restricted to one per 
> campus/regional/national network so that we can really get the picture 
> mentioned above; and that also an IPv6 instance of the beacon (embedded 
> RP+SSM) should run alongside the IPv4 beacon, where possible.

> Admittedly this is not an easy task, but if someone (e.g. Internet2) were 
> to jumpstart such an initiative, I am confident that a large number of 
> sites/networks would be quick to join in. I can say that GRNET NOC has been 
> contemplating such a thing (especially decommissioning mbeacon) for quite 
> some time.
> 
> Best regards,
> Zenon Mousmoulas
> GRNET
> 
> PS: What is missing from dbeacon is non-interactive monitoring and 
> alerting. Maybe dbeacon could be enhanced or one could parse its' log. 
> Deciding when to raise alarms, however, would be a tricky subject.
> 
> -----Αρχικό μήνυμα-----
> Από: 
> 
>  εκ μέρους Scott Bertilson
> Αποστολή: Πεμ 19/5/2011 12:21 μμ
> Προς: Curtis, Bruce
> Κοιν.: Multicast Working Group
> Θέμα: Re: NCSA Beacon page gone after 5/30/2011
> 
> I've talked to people at NCSA several times over the last several years
> (usually asking them to restart the server) since they took it over and
> they've consistently said they'd really like to unload it.  One of the
> biggest reasons is that the code wasn't designed for the number of hosts it
> is often currently tracking and that or something else causes the app to
> bomb repeatedly.  Too bad there isn't some sort of multicast tracking tool
> included in the perfSONAR toolkit.  I've never thought to ask, but I wonder
> if they would consider it.  If so, it would probably be better to build it
> using dbeacon rather than using this ancient chunk of perl.  Maybe they
> would allow something to be included but defaulted to disabled.
> 
> Scott
> 
> On Wed, May 18, 2011 at 5:24 PM, Curtis, Bruce 
> <>wrote:
> 
>> 
>> I see that the NCSA Beacon page will be gone after 5/30/2011.
>> 
>> http://beacon.dast.nlanr.net/
>> 
>> Looks like they are looking for someone to take over hosting the multicast
>> beacon.
>> 
>> ---
>> Bruce Curtis                         
>> 
>> Certified NetAnalyst II                701-231-8527
>> North Dakota State University
>> 
>> 
>