Your application developers have decided to write a new application for sharing corporate information, your traders need access to financial feeds, desktop support need a better way of downloading upgrades to specific machines, and HR wants to introduce online training packages. And they all use multicast.

We've previously looked at the mechanics of multicast and how to implement it, but how do you check you've set it up right, short of actually deploying the user application and seeing if it works?

That's not a good idea for two reasons. One, if it's a new application, you'll be struggling to prove whether any anomalies are due to the network configuration or the application itself, and two, waiting till the app's ready to roll is leaving it a bit late - and you don't want to let on to the developers that you're not 100 percent confident you've done your bit right.

But test sets that can generate multicast traffic can be costly, and you'd need several of them - or one with multiple independent interfaces - to make sure that the generated traffic is seen where it should be, and, as importantly, isn't received where it shouldn't be.

Test applications
The best way to see if you've got your config right is to poke a multicast stream into the network at one point, and see it popping up on a client PC somewhere else. There are several freely available applications you can download to use for this testing.

Timecast for example, is a one-to-many application that multicasts the time, using the multicast-enabled WinSock API. VBrick's StreamPump and StreamPlayer applications are a bit more user-friendly and impressive for testing purposes - installing these on multiple PCs lets you stream MPEG files across your network to make sure they only appear on the PCs that have subscribed to the multicast group you've set up.

If you work in an academic organisation, or can get access to JANET, you can make use of its multicast testing facilities by subscribing to its multicast beacon signal and setting up a beacon client.

Monitoring traffic
Now that you have a server and at least two clients, it's pretty easy to confirm that multicast is getting your traffic to where to needs to go, simply by looking at the screen on your receiving PC. But you also need to investigate the other segments in your network, to ensure that your multicast configuration isn't simply broadcasting the traffic everywhere.

On a test network, where you can control other background traffic, it's enough initially just to look at traffic levels to see which parts of the network are carrying your multicast streams. You should be able to see pretty dramatic changes in utilisation as receiving PCs join and leave a sending group - remember that it's also important that the traffic stops being sent out onto a LAN when the last valid receiver leaves, otherwise you lose the whole benefit of multicasting, rather than just flooding the data everywhere.

To get a better feel for what's actually happening on the network, your routers should be able to tell you which groups they're seeing traffic for, where the receivers and sources are and on which interfaces they are sending traffic. Remember to start at the receiver end when you're troubleshooting multicast traffic, not at the source as you typically would when you're investigating normal unicast traffic.

Watch to see how long it takes for timeouts to kick in after you shut down a receiving application. Is there a difference if the application is closed gracefully or if you just reboot the PC? This sort of information will be useful later when you need to troubleshoot your 'real' application and don't have the same testing leeway.

While you're at it, try some failures to see how quickly your multicast tree can rebuild itself if you lose a Rendezvous Point, or a device in the path. And be careful how recovery is handled, to make sure you don't end up with two streams if the preferred path re-establishes itself and the backup for some reason keeps transmitting.

Multicast-enabling your network isn't a dark art. It's deterministic and once you get the hang of it you can easily see what's going on. But to begin with, it takes some time to get your head round what your network devices tell you is going on, and it's not the sort of thing you want to be learning with a new application due to hit the users' desks, and the software guys standing over your shoulder. So configure it up, get yourself some test software and make sure you understand how it fits together before anyone asks you to.