Bonjour control

  • 19 May 2016
  • 4 replies

Hi, I understand that Extreme policy can control the Bonjour traffic. So, here I have two questions;

(1) Is there any demerit when I make a policy that AP rejects the bonjour packet at the edge?

(2) Usually, how much percentage of the traffic occupied by the bonjour traffic?

Thank you in advance.


Yutaka Sasaki

4 replies

Userlevel 5
I've had quite a few requests through the years where the switch can have a lot of trouble once bonjour is introduced in the network. The problem is that it can be a very chatty protocol and if you have a lot of different endpoints sending, it can quickly get out of hand. If you can cut it off at the AP instead of it going to the switch, I can only see it improving things.
Userlevel 7
A big problem with Bonjour (or any other link-local protocol used by many clients) on Wi-Fi results from multicasts (and broadcasts) being sent with the slowest transmission speed of the Wi-Fi version used. Many multicast packets thus result in a lot of airtime wasted by these protocols, without a real benefit.

On a wired network they can cause a problem with IGMP snooping, because practically every client both sends an receives the respective multicast groups, which results in many IGMP snooping entries, possibly too many for the switch.
Hi Brad, Hi Erik,

Thanks a lot! Both of your comments are very helpful to me.
Userlevel 7
Another problem with Bonjour, MDNS, and LLMNR multicast traffic using group addresses within is the associated CPU load of switches. If a switch receives a multicast packet with group address in this range on an IP interface, it will forward this packet to the CPU. This results in increased CPU load.

The GTAC Knowledge Article How can I block mDNS with an ACL using MAC addresses is related to this problem.