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? _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
