Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Multicasting: Not pruning stub routers

I have a WAN comprising 13 routers, with 5x 2M serial and 3x 34M microwave ATM WAN links.

4500M (11.3T), 4700 (11.3T), 4700M (11.2), 2620 (x4) (12.0(5)T), 2621 (12.0(5)T), 2514 (11.2), 3660 (12.1), RSFC (2)(12.1), MSFC2 (12.1).

Multicast traffic flows across all links. On stub routers that serve just an ethernet port (remote site), the traffic is pruned on the local interface, and it claims to be pruned on the serial WAN link, but the traffic is still flowing across the link, eating up bandwidth. The up/down? stream router is still sending.

All local interfaces are ip pim sparse-dense-mode/ip cgmp, and all wan links are ip pim sparse-dense-mode. There are no auto-rp or rp's defined.

Does anyone know how to stop this traffic? It may need to flow to these remote sites still on demand. I am aware of a manual method of pruning stub routers, but if you read the cisco docs on pim and the like, it should prune automagically.


Re: Multicasting: Not pruning stub routers

Since there has been no response to your post, it appears to be either too complex or too rare an issue for other forum members to assist you. If you don't get a suitable response to your post, you may wish to review our resources at the online Technical Assistance Center ( or speak with a TAC engineer. You can open a TAC case online at

If anyone else in the forum has some advice, please reply to this thread.

Thank you for posting.

New Member

Re: Multicasting: Not pruning stub routers

I ran into this same problem in my LAN with 20+vlans (4 msfc's), which equaled a ton of traffic and the cpu load shooting up.

Since you're using sparse-dense-mode, define the rp on your router closest to the multicast traffic: ip pim rp-address (loopback since it's always up). With only 1 mcast group you should be fine with one rp. Note that 1 rp can cater for as many mcast groups as you like, its just better for scalability and position of the mcast source within the network is why multiple rps for different mcast groups are chosen.

Here's some good links:

Hope this helps,