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

[Clarke Morledge]

Chuck (or anyone else who might know):

Would it be sufficient to say that handling of QoS markings might help to 
mitigate against this problem impacting CPU performance?  But would it 
help in the situation where the switch itself needs to mark the packets 
for QoS?  Would the marking (and thereafter the QoS processing) of the 
packets happen on the PFE before it hits the CPU?

Clarke

On Wed, 13 Nov 2013, Chuck Anderson wrote:

> 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?
>