[j-nsp] EX cpu performance under multicast replication load?
cra at WPI.EDU
Wed Nov 13 14:39:31 EST 2013
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:
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?
More information about the juniper-nsp