Multicast Addressing for Departmental Applications


If you are using a multicast-based application for desktop disk “imaging” or “ghosting”, please configure your system to use a multicast address in the range of –

Detailed Explanation

As we watch the flow of network traffic across the campus, one thing we notice is the increasing number of operating system functions and applications that utilize IP multicast (go here for a quick overview, if you’re unfamiliar with the technology). In particular, we see more folks using desktop “imaging” applications (i.e. pushing a disk image out to desktop systems, usually to build or rebuild numbers of systems at once) that utilize IP multicast. Many of these applications use a default multicast IP address for their group address, meaning that not only do your department desktops “join” that multicast group, but so may others that aren’t in your department.

As such, the imaging traffic that is going from your server to your departmental desktop(s) may also be traveling over the entire network to other departments that don’t need to see that traffic – multicast traffic doesn’t stop at VLAN boundaries; it goes wherever it sees “group” members, regardless of VLAN. Now, there is no issue with those other desktops getting their images re-written – the client application is smart enough to know to reject traffic it shouldn’t be getting, but that traffic does travel all the way to the “joining” systems anyway.

The good news is that, from what we’ve seen, more and more of these applications allow you to define the group multicast IP address that you want to use. Problem is, most people either don’t know what that means and leave the default or leave the default because it’s not causing any problems for them.

Following the recommendations of Internet RFC 2365, which defines best practices for administratively scoped IP multicast, we would like to encourage departments to utilize the space defined as the IPv4 Local Scope for multicast addresses. According to the RFC, the exact extent of a Local Scope is site dependent. That being the case, we are officially stating that the extent of a “Local Scope” for multicast is a VLAN boundary. As such, we have implemented router filters for all VLANs that we know are using multicast applications to keep any traffic destined to (meaning addresses from –; note the addresses with a third octet of .255 are reserved for special addresses) confined within that departmental VLAN, regardless of whether or not any device outside of the departmental VLAN has “joined” one of those addresses.

When you do select a address to use for one of your multicast-based applications, please send a ticket to Networking with the address that you’re using and we can uniquely register them to avoid potential conflicts even within your own department, as well as verify that your departmental VLAN is properly set up with this multicast filter.

More Information

If you have any questions, please contact Networking through the ITS Response Center at 962-HELP.

Jim Gogan, Information Technology Services (ITS)