All things related to multicast

["Zenon Mousmoulas" <>]

Hi Debbie,

you have a point about the unicast updates with mbeacon, on the other hand I 
suppose that could be one of the reasons why it was reported that "the code 
wasn't designed for the number of hosts it is often [currently] tracking".

You are right again that dbeacon also seems to be abandoned. In fact, I just 
noticed that mbeacon v1.4 was published on SourceForge on 2011-02-05, with 
the following note included in the ChangeLog:

Beacon v1.4-0                   February 4, 2011
* Set udp socket buffer sizes as large as OS limits allow.

* Build shared libraries using -fPIC

* Add a FreeBSD rc.d startup script.

On the other hand, dbeacon has these probably important (nowadays) features:
- IPv6
- SSM

So the question is: Are there any other/better options for beacon software?

BTW, when the dbeacon code was declared abandoned, about one year ago, it was 
re-licensed with an MIT license and published on github: 
http://github.com/hugosantos/dbeacon


As for what group to use, the bottom line is it doesn't matter that much. 
Despite GLOP or RFC6014 assignments, I don't think anyone stops anyone else 
from using each other's address space, or that would technically make much 
sense anyway. Nonetheless, for IPv4 ASM specifically, I would personally be 
in favor of using something "neutral", so in this sense I would suggest 
either of the following:
- Consider applying for an assignment in the AD-HOC Block III 
(233.252.0.0/14), risking rejection because such an application could be 
perhaps debated to imply the resurrection of an "mbone", and also accepting 
the delay associated with the review/approval process, or even simply (ab)use 
a group in the MCAST-TEST-NET block (233.252.0.0/24, reserved for example.com 
type of use).
- Just use a memorable group address from the GLOP block, that is not already 
used by the assignee, after asking for his permission, of course. According 
to such criteria the ideal candidate would be, IMHO, 233.4.5.6, assigned to 
AS 1029; I don't know who that is, but see: 
http://whois.arin.net/rest/asn/AS857/pft

To conclude, I agree that all it takes is agreeing on a group to use, as you 
noted. I would add to that: a number of sites must join this beacon, so that 
critical mass is achieved. This relates to my previous suggestion about 
jump-starting such an initiative.

Best regards,
Z.

-----Αρχικό μήνυμα-----
Από: 

 εκ μέρους Debbie Fligor
Αποστολή: Τετ 1/6/2011 12:03 πμ
Προς: Multicast Working Group
Κοιν.: Debbie Fligor
Θέμα: Re: NCSA Beacon page gone after 5/30/2011
 
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
>> 
>> 
>