[c-nsp] IP multicast traffic overwhelms switches

[Jay Ford]

On Fri, 10 Jul 2009, victor wrote:
> We are getting ready a residential triple-play network for the launch. As 
> part of my job I'm conducting various tests on its performance, delays, 
> etc before we go into production. Today was the multicast time and testing 
> it I got very discouraging results. Under very moderate load of 15 IPTV 
> streams (each approximately 1-1,5Mbps) the cpu gauge on the core C7604 
> increased by 15% but on the distribution C4924 hit 50% from zero!  When I 
> went on with the test and launched iperf adding one more 50 Mbps stream in 
> udp multicact mode to stress-test both even more the cpu utilization on 
> C7604 became 60% and on C4924 hit 100%. It even became visible as the 
> responses of the telnet console considerable slowed down.
> Both switches work as ip multicast routers in sparse-dense mode. The RP is 
> C7604. Apparently all the multicast traffic gets process switched, though 
> I explicitly entered “ip mroute-cache” under every interface.
> Did someone encounter something similar? Is it expected behavior? Is there 
> a way to force cef to do it's job. Specs say that  C4924 can switch/route 
> up to 72gbps irrespectively of L2/L3/L4 protocol.

I don't think you want “ip mroute-cache”, at least not on 7600/6500 boxes. 
My guess is that by configuring that you're disabling the hardware-based 
forwarding & forcing it to software-based forwarding.  Get rid of the “ip 
mroute-cache” & see if things get better on the 7600.

Are the 4900 boxes doing L3 or just L2?  I suspect they'd do much better at 
L2 fan-out of multicast than at L3 fan-out.  You're probably hitting a pps or 
packet replication limit before hitting the bps limit.

________________________________________________________________________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-ford at uiowa.edu, phone: 319-335-5555, fax: 319-335-2951