Where do I get technical support for Multicast issues?

While we would love to be able to diagnose each and every individual problem discovered by the Multicast Beacon, unfortunately, we simply don't have the time or the resources to do so.

What we can do, however, is suggest that you talk with your local network support staff and see what they can tell you. Also, please check the following list of links for additional support and information:

Courtesy of Andrew Daviel, at TRIUMF in Canada

How do I know if my network has multicast?

The Beacon is a Perl script, so anyplace you can get Perl to run, you should be able to get the Beacon to run. It requires Perl 5.6 or better.

The Net::Multicast::Beacon Perl module has been compiled successfully under Linux 7.2 and better, Fedora Core 1 and 2, and on FreeBSD 4.7 and better. There is no Win32 version yet, but if you wanted to compile one and give it to us, we'd be happy to include it here.

The Central Loss page is generated at the Central Beacon Server via individual TCP reports from each Beacon back to the Central Beacon Server. This is done in order to avoid any potential problems that might be going on in multicast at the moment, preventing one set of Beacons from seeing another set of Beacons.

Theorectically, if multicast was working perfectly everywhere in the world, the Local Loss and Central Loss pages will be identical. However, given that multicast doesn't always (*ahem* ;-) ) work perfectly, the Central Loss page is the only way to see all the Beacons running in a given multicast group. (And even that falls prey to bad TCP connections, firewalls, misconfigured routers, etc., sometimes. But it's much more robust than the UDP reporting the old Beacon did.)

The Beacon sends UDP traffic on ports 10002 and 10003 of the curent multicast group, and TCP traffic on unicast port 10004.

The colors indicate different conditions. Usually green means normal, yellow means warning, and red means trouble. The bottom of each page describes the specific values for each criterion being measured.

On many Linux installations InetAddress.getLocalHost() may return an InetAddress representing the loopback address (127.0.0.1). This stems from many Linux installations configuring /etc/hosts to map the hostname to the loopback address. If the host has a static IP address then the /etc/hosts file should be corrected to map the hostname to the host address. If your Linux host is using DHCP, check /etc/sysconfig/network and make sure the machine name appears correctly there.

As far as I know, there are no security vulnerabilities with the Beacon. But in the event that someone finds a bug in the Beacon that allows it to be compromised, a malicious user could potentially end up on your box as whatever user the Beacon is running as. Do you really want that user to be "root"? I strongly recommend that you always run your Beacon as an unprivileged user. Check out the RUNASUSER option in beacon.conf, and consider setting up a non-privileged user for the Beacon.

Install the NTP package (e.g. RedHat RPM "ntp")

The beacon doesn't use IGMP, it uses RTP.

When the beacon starts listening, your operating system uses IGMP to tell your local network that you are interested in the multicast group. Which version you have depends on your operating system - v1 for Win95 maybe, v2 for Win2000 and Linux 2.4, v3 for WinXP and Linux 2.6. Also, if your router is v2 your O/S should back down to v2 mode unless you have problems with switches in the way.

Then your local router needs to have IGMP enabled, PIM-SM enabled, and needs to know where to send PIM requests. Normally it would have a PIM RP configured upstream or some more complicated protocol enabled (MDSP, MGBP etc...)

You should be able to see (with a sniffer) your system sending IGMP reports, and you should be able to see that your router has heard them and is doing something about it.