mDNS traffic flow

[davidj_cogliane]

We have seen several customers experience different issues involving mDNS traffic causing congestion or not be handled as expected. The testing we have done also has created more questions than answers.

It seems all 224.0.0.x traffic goes to the CPU by default which causes issues on x460-G1 switches. We currently have one site where we are blocking 224.0.0.252/32 LLMNR, with a deny, and 224.0.0.251/32 mDNS with deny-cpu, we are also blocking 239.255.255.250/32 SSDP, with a deny.

This has greatly improved switch and Network performance but I have not yet received verification that Apple TVs and Chromebooks are operating as expected.

Some testing we did our lab with code 16.2.4.5-patch1-3 and 16.2.3.5-patch1-3 seems to indicate that blocking mDNS with deny-cpu causes the switch to also stop forwarding mDNS from the data plane.
Is this the expected behavior?
What is the recommended treatment of these traffic types?

We see more and more of this on school networks and are wondering if we should create ACLs to block this traffic from the CPU as a default configuration even on G2 switches.

Thoughts or experiences?

We have also seen a switch not relay mDNS packets between Apple TVs and an Aruba controller. Through packet captures we determined everything was making it to the switch and igmp snooping was configured and the appropriate ports were in the mcast cache. We turned off igmp snooping for the VLAN and suddenly the packets began to flow.

Any thoughts or similar experiences?
We found some documentation that seemed to indicate 224.0.0.x was except from igmp snooping.
Is that correct?

[MariaHende]

Thanks for information!

[Muslim]

mDNS, LLMNR, and SSDP have become major sources of unexpected CPU load on school networks, especially on older hardware like the x460-G1. What you’re seeing with deny-cpu blocking not only CPU processing but also data-plane forwarding is consistent with how these switches handle link-local multicast ranges. Many admins prefer targeted filtering or rate-limits instead of full blocks when Apple TVs, Chromebooks, or discovery-dependent services are involved.

Your findings with IGMP snooping also match real-world behavior 224.0.0.x traffic is link-local and often bypasses snooping logic entirely, which explains why disabling it suddenly allowed devices to see each other again. In situations like this, analyzing traffic patterns holisticallysimilar to how Water Treatment Solutions monitoring approach reviews system load can help determine whether ACL-level filtering is the right long-term fix.

Overall, G2 switches handle multicast more gracefully, but adding default ACL rules for LLMNR, SSDP, and high-volume mDNS is a solid baseline if you verify that discovery services still function properly across your environment.

[Patrick_Voss]

Hello David,

If MDNS and LLMNR are needed you can try to utilize the following command:

"configure forwarding ipmc local-network-range fast-path"

You will need to keep the following in mind when you implement this:

***
Fast-path forwarding dictates that packets traversing the switch do not
require processing by the CPU. Fast path packets are forwarded entirely by
ASICs and are sent at wire speed rate. This consumes additional system ACL
per-port or per-VLAN, depending on configure igmp snooping
filters [per-port | per-vlan] selections.
***

This means that if you are utilizing any other protocols that fall within the local network range(OSPF and VRRP) they will not be processed by the CPU.

It will probably require a reboot and since you have a lab setup shouldn't be that hard to see if it resolves the issue you are seeing.

Everything else you are talking about seems correct. The 224.0.0.x traffic can affect a network based on a couple factors. The design, size of the subnet or even the size of the stack because the switch takes in this traffic and replicates it out all ports in that VLAN. I have seen cases where this traffic can be sent out at an alarming rate from the PC side. I am not completely sure if this has been resolved but here is one post that I found while searching for it:

https://social.technet.microsoft.com/Forums/en-US/b334e797-ef80-4525-b74a-b4830420a14e/windows-10-sp...

The G2 switches may be better equipped to handle the traffic. They do have a stronger CPU and may not show the same symptoms.

The 224.0.0.x subnet is considered local multicast and most of it will be exempt from IGMP Snooping. There are some protocol traffic like OSPF and VRRP that will not be exempt from IGMP Snooping.

Hope I answered all your questions.