Multicast on the UIUCnet Network

For IT Pros
This page contains information about the way multicast networking is implemented on the campus network.

What is multicast and why is it useful?

At its most basic, multicast is a method to get data from one or more sources to multiple receivers with the least amount of network traffic possible.

A multicast group is a single IP address from the designated multicast IP range that typically defines a specific service.

Traffic from a source goes out to the multicast group as a single packet, and the packet only goes to those places in the network that want to receive it.

If there's only one host on the network that wants to receive the packet, there is no real savings over unicast.

However, if there are 10 hosts on the network that want to see the packet, they all get the information from the same single packet. Therefore, multicast is helpful to the network as there is less total traffic being sent, and it is also helpful to the server that only had to send a packet to a single IP address instead of sending separate packets to each of the interested IP addresses.

Some of the multicast-capable services on our campus include Norton Ghost for imaging multiple hard drives at the same time; video collaboration suites like Access Grid; and server location protocols for finding printers and other network services.

Upcoming multicast-based services could include TV channel delivery as well as streamed audio and video from various sources on or off campus.

How does multicast work on my local network?

The multicast standard was developed when bus networking (thick and thin Ethernet) was the norm, and it was assumed that all stations on a network would see any multicast packet. When network switches changed the nature of a network so that only traffic for a specific MAC address went out any given port, multicast would no longer work if the traffic wasn't handled differently. In order for multicast to continue to work as designed, switches would have needed to send any multicast traffic out to all ports.

This behavior was what switches were supposed to prevent, so now modern switches "snoop" IGMP (the protocol that hosts use to tell routers that they want to join a multicast group). IGMP uses join and leave requests to let routers know what hosts want to see which multicast group. A router works at the IP layer and normally looks at the IP address in a packet. In contrast, switches don't normally look at the IP information to make decisions, just the MAC addresses.

IGMP snooping in more detail

IGMP snooping is a feature that allows the switch to discover which ports have hosts that want to receive multicast traffic, as well as to send switch-wide requests to the router (or the next hop switch) so that the upstream devices know that there are hosts that want to get a specific multicast group. This is much more than just passive "snooping" and is quite complex to get right.

In order for IGMP snooping to work on a switch, two things must happen:

  1. IGMP snooping must be enabled.
  2. There must be an IGMP querier on the network. The IGMP querier is the device that notices that the hosts are requesting to join groups, and it sends out regular queries to see if there are still any hosts out there that want to continue to get the group.

Which device on a network is the IGMP querier?

If a network's router to campus is set to enable multicast, it functions as the querier.

If the router does not offer multicast, another querier has to be configured on that subnet for IGMP to work correctly in the switches.

Some brands of switches can serve as queriers; others can not.

The IGMP standard says that even if IGMP is turned on, if there is no querier, all multicast traffic should flood to all ports. However, not all switches follow that standard; some err on the side of caution and pass no multicast traffic if IGMP is turned on but there is no querier.

How does multicast work on UIUCnet?

The UIUCnet network core has IP multicast enabled between all the different parts of campus. In the past, multicast was turned off by default on any given subnet. Under the current standards, multicast will be turned on by default for new networks unless it is requested to be off.

Existing networks wishing to use multicast to the campus (or to off-campus) need to request for it to be enabled. A network contact for your unit or department can send the request by email to net-trouble@illinois.edu.

Someone from CITES Networking will be assigned to help make sure IGMP is enabled in all the switches correctly before multicast is turned on.

Different network paths are used for sending and for receiving

Sending multicast and receiving multicast are two totally different issues. Multicast traffic paths are built from the receiver toward each of the senders. Therefore, even if a single host is both sending and receiving traffic, the routers and switches in the path of the traffic have to build two totally different trees for the data to travel. So when working with multicast, it is quite possible to have one direction working and the other not working (for example, sending is working but receiving is broken, or the other way around).

Troubleshooting

IP multicast is a moderately complex protocol and CITES sometimes experiences bugs and interoperability issues with it in the campus network equipment. CITES does its best to keep multicast up and working, but multicast is not always functional. If you have an application that relies on multicast to work to places off your network, please work closely with CITES so that the team can do its best to keep multicast working for you.

If you need to report a problem with multicast, there is some information that will need to be gathered in order for us to look at it.

How does multicast work between the Urbana-Champaign campus and other places?

To reach off campus and NCSA, multicast traffic goes first through our exit, onto the ICCN, and then out to the rest of the world. We exchange multicast routes with three of our peers, one of which is NCSA, in addition to the ICCN. The ICCN exchanges multicast information with four additional peers. This multi-point peer-based exchange of information provides access to most things multicast on the research internet and often beyond. Multicast between the Urbana-Champaign campus and the UIC campus should work via the ICCN peering.

Off campus multicast requires for both the campus multicast and the peer connections to be working reliably. In the past CITES has had some problems with peering staying stable; however, at this time, the equipment in the exit architecture appears to have that part of multicast much more stable and reliable.

If you are trying to use multicast for something sent off campus and are having problems, please contact CITES through your network contact at net-trouble@illinois.edu.

I want to start a multicast stream. Where do I get an address?

There are only 256 Internet-broadcastable multicast group addresses available for the Urbana-Champaign campus to use.

There are 65,000 addresses available to use within the UIUCnet network space. In the future, there will be an additional 65,000 addresses that can be used for multicast traffic distributed between the three University of Illinois campuses at Urbana-Champaign, Chicago, and Springfield. CITES manages these multicast group addresses.

To request an address assignment, send email to multicast@illinois.edu. In the email, please describe: