To understand why this occurs, we need to review the multicast operation. IGMP is part of the IP layer on host and routing devices. Its primary responsibility is to control the addition and deletion of host processes from one or mor e multicast groups. IGMP's host portion does not add a significant processing load to the hosts, but it can occasionally become burdensome to routers.

IGMP uses a query-and-response model to generate and maintain a table that lists which interfaces on the router have one or more hosts belonging to a multicast group. Each set of hosts listening to a particular multicast IP address is termed a host group. Remember that host groups can span multiple networks.

The IGMP processes on the router and the multicast routing protocol used combine to define how packets for each host group are routed through the network. Typical multicast routing protocols include DVMRP (Distance Vector Multicast Routing Protocol), MOSPF (Multicast Open Shortest Path First) or PIM (Protocol Independent Multicast), which is Cisco Systems' proprietary protocol.

Depending on the technology deployed, a fault in the network re sults in the execution of either the Spanning Tree algorithm or Dijkstra algorithm to recalculate routes. This is the part that can cause difficulties.

Both Spanning Tree and Dijkstra are industry standard protocols and work well in the environments they were originally designed for. Spanning Tree was designed to allow multiple physical paths between Layer 2 bridge ports by discovering a loop-free path between nodes and electing only certain ports of a bridge to participate in forwarding packets. Dijkstra was implemented as the basis for linking state routing environments and essentially calculating routes for entry into a routing table within an OSPF (or other link state protocol) area.

Dijkstra, however, has always been known to be CPU-intensive. The difference here is that a multicast routing process needs to consider the entire network when recalculating appropriate routes for multicast traffic packets. This requirement significantly increases the number of calculations the router has to perform. As a result, the router is so busy recalculating routes that packets can be dropped during this period.

The exact number of routes when you begin to encounter problems depends on the processing power of the routers. Anything greater than 40 routes should be tested before being implemented.

Using PIM in dense mode alleviates problems, but you can lose some redundancy. Dense-mode PIM relies on a rendezvous point on the network where all multicast senders and receivers register. If this rendezvous point becomes unreachable on the network for any reason, the multicast application will stop working.

With the protocols available at the moment, no simple solution to this problem is in existence. The best advice, for now, is to use dense-mode PIM or do everything possible to minimize the number of routes in the routing table.