[j-nsp] EX cpu performance under multicast replication load?

[Chuck Anderson]

If the multicast traffic is using a group that shares the same
multicast MAC address as some control-plane protocol groups
(224.0.0.X) then the RE CPU needs to get a copy of all those packets
in case it needs to act on possible control plane traffic.  This is a
problem that most switches have.  See:

http://web.urz.uni-heidelberg.de/Netzdienste/docext/3com/superstack/3_0/3900/2i3igmp6.html

On Wed, Nov 13, 2013 at 11:33:57AM -0500, Clarke Morledge wrote:
> I am seeing some bothersome CPU performance issues on EX switches,
> mostly on the less powerful units like the 2200s, when it comes to
> handling multicast.
> 
> In practical situations, I do not see much multicast traffic in
> general, except on our campus we do get a lot of Apple Bonjour
> traffic related to Multicast DNS.  Sometimes, a single host will go
> a little bonkers with repeated MDNS packets.   In one case, I have
> seen where a flood of about 100 multicast packets per second,
> related to Bonjour, will cause the CPU on the lower end EX switches
> to spike up dramatically, resulting in loss of management of the
> switch during peak loads.   For example, the switch will stop
> handling ICMP echo requests to its management IP, or it will miss
> RADIUS packets.
> 
> Can someone walk me through the EX architecture a bit to tell me if
> this is expected behavior?  I am assuming the EX CPU is actually
> handling the multicast replication of Ethernet frames received to be
> sent out other ports, but it seems like 100 packets per second
> should not be a big deal to worry over.  So something looks awry.
> 
> Oddly enough, I do not see any performance issues when straight-up
> broadcast traffic hits these kind of packet rates.
> 
> To mitigate against this, I guess I could use QoS to prioritize
> management frames over user multicast data, but if the issue is
> about packet replication and not forwarding, I am entirely convinced
> that the standard
> marking and handling QoS parameters would be effective.
> 
> Any ideas?