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