All things related to multicast

[Debbie Fligor <>]

On Jun 1, 2011, at 12:32, Zenon Mousmoulas wrote:

> 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:

Thanks, I  missed that this had been released.

> 
> 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

agreed.

> 
> 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.

I see your point about choosing the address as something memorable, but we 
lived on 233.4.200.18 for years, so I don't think it's too critical.

A little bird told me we might be seeing someone pickup the mbeacon server, 
and perhaps someone else offer up a central web site to track dbeacon users 
of a global group.  But those are both down the road.  For the moment, anyone 
is welcome to use 233.0.38.38 for a global dbeacon group.  Please limit 
yourself to 1 host per site, my end of this is a little, old, Mac mini, but 
you should be able to look here:

http://bbmon2-1.gw.uiuc.edu/matrix-global/

and see if you're making it to my campus (or not).

If someone else has a nicer group address to offer, I'm happy to change.  I 
can't offer IPv6 multicast or SSM, since we don't have those here, but there 
is nothing stopping people from running those features as well and making it 
even more useful.

Sorry it took me so long to get back to this thread, a few other things (like 
IPv6 day work) trumped me  having time to work on this.  But I did get one 
host up and the web page working. 

-debbie

> 
> 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
>>> 
>>> 
>> 
> 
> 
> 
> 

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

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






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

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