Wireless Access

If Airgroup is disabled, I think it's really unlikely that the controller is replicating mDNS across VLANs.

Do you see the mDNS traffic replicated/originating from there? Also, it may be that if you have a WLAN with users in multiple VLANs, and you don't do broadcast/multicast filtering, the bc/mc traffic (which mDNS is) may be replicated through that. It can also be that another device is proxying that mDNS.

Also note that many devices, have moved to Bluetooth discovery and go outside of the WLAN.

It depends a bit on what you have exactly seen. If you can't find the issue, it may be good to work with TAC and find what's going on.

Are you saying that it is intended behavior to flood mDNS traffic to every client on a WAN, regardless of the user's role's VLAN assignment?

If Airgroup is disabled, I think it's really unlikely that the controller is replicating mDNS across VLANs.

Do you see the mDNS traffic replicated/originating from there? Also, it may be that if you have a WLAN with users in multiple VLANs, and you don't do broadcast/multicast filtering, the bc/mc traffic (which mDNS is) may be replicated through that. It can also be that another device is proxying that mDNS.

Also note that many devices, have moved to Bluetooth discovery and go outside of the WLAN.

It depends a bit on what you have exactly seen. If you can't find the issue, it may be good to work with TAC and find what's going on.

Do you have BCMC controls enabled?

Are you saying that it is intended behavior to flood mDNS traffic to every client on a WAN, regardless of the user's role's VLAN assignment?

If Airgroup is disabled, I think it's really unlikely that the controller is replicating mDNS across VLANs.

Do you see the mDNS traffic replicated/originating from there? Also, it may be that if you have a WLAN with users in multiple VLANs, and you don't do broadcast/multicast filtering, the bc/mc traffic (which mDNS is) may be replicated through that. It can also be that another device is proxying that mDNS.

Also note that many devices, have moved to Bluetooth discovery and go outside of the WLAN.

It depends a bit on what you have exactly seen. If you can't find the issue, it may be good to work with TAC and find what's going on.

I don't want to block all mDNS traffic, I just want it not to cross VLANs. 

Do you have BCMC controls enabled?

Are you saying that it is intended behavior to flood mDNS traffic to every client on a WAN, regardless of the user's role's VLAN assignment?

If Airgroup is disabled, I think it's really unlikely that the controller is replicating mDNS across VLANs.

Do you see the mDNS traffic replicated/originating from there? Also, it may be that if you have a WLAN with users in multiple VLANs, and you don't do broadcast/multicast filtering, the bc/mc traffic (which mDNS is) may be replicated through that. It can also be that another device is proxying that mDNS.

Also note that many devices, have moved to Bluetooth discovery and go outside of the WLAN.

It depends a bit on what you have exactly seen. If you can't find the issue, it may be good to work with TAC and find what's going on.

Not asking you to block everything, just asking if you have BCMC enabled in any way.  Do you have DMO enabled?

I don't want to block all mDNS traffic, I just want it not to cross VLANs. 

Do you have BCMC controls enabled?

Are you saying that it is intended behavior to flood mDNS traffic to every client on a WAN, regardless of the user's role's VLAN assignment?

If Airgroup is disabled, I think it's really unlikely that the controller is replicating mDNS across VLANs.

Do you see the mDNS traffic replicated/originating from there? Also, it may be that if you have a WLAN with users in multiple VLANs, and you don't do broadcast/multicast filtering, the bc/mc traffic (which mDNS is) may be replicated through that. It can also be that another device is proxying that mDNS.

Also note that many devices, have moved to Bluetooth discovery and go outside of the WLAN.

It depends a bit on what you have exactly seen. If you can't find the issue, it may be good to work with TAC and find what's going on.

Perhaps I am mistaken, but I was under the impression that BCMC blocks all mDNS traffic unless AirGroup is enabled. That's what the 8.10.0.0 User Guide Suggests.

I had not looked at DMO. I just read about it in the ArubaOS 8.10.0.0 User Guide, and it seems to suggest that its purpose is to improve multicast efficiency by converting it to unicast, but the wording suggests that it doesn't do that for all multicast traffic.

Not asking you to block everything, just asking if you have BCMC enabled in any way.  Do you have DMO enabled?

I don't want to block all mDNS traffic, I just want it not to cross VLANs. 

Do you have BCMC controls enabled?

Are you saying that it is intended behavior to flood mDNS traffic to every client on a WAN, regardless of the user's role's VLAN assignment?

If Airgroup is disabled, I think it's really unlikely that the controller is replicating mDNS across VLANs.

Do you see the mDNS traffic replicated/originating from there? Also, it may be that if you have a WLAN with users in multiple VLANs, and you don't do broadcast/multicast filtering, the bc/mc traffic (which mDNS is) may be replicated through that. It can also be that another device is proxying that mDNS.

Also note that many devices, have moved to Bluetooth discovery and go outside of the WLAN.

It depends a bit on what you have exactly seen. If you can't find the issue, it may be good to work with TAC and find what's going on.

Are you saying that it is intended behavior to flood mDNS traffic to every client on a WAN, regardless of the user's role's VLAN assignment?

If Airgroup is disabled, I think it's really unlikely that the controller is replicating mDNS across VLANs.

Do you see the mDNS traffic replicated/originating from there? Also, it may be that if you have a WLAN with users in multiple VLANs, and you don't do broadcast/multicast filtering, the bc/mc traffic (which mDNS is) may be replicated through that. It can also be that another device is proxying that mDNS.

Also note that many devices, have moved to Bluetooth discovery and go outside of the WLAN.

It depends a bit on what you have exactly seen. If you can't find the issue, it may be good to work with TAC and find what's going on.

That is how WLAN/WPA works in the standard. There is a shared key for broadcast traffic for all clients on a specific (B)SSID, the GTK, as the idea of broadcast is that everyone should be able to see that traffic, and if clients on the same SSID are on different VLANs, all clients see broadcast traffic for all VLANs active on the SSID. In most situations this is not an issue, but it is with mDNS as well with IPv6 RA traffic, and probably other protocols.

The solution around that is broadcast filtering, Airgroup and BC/MC to unicast conversion; but it seems you don't want to enable that.

BTW, that this is causing your issue is pure speculation and one possible reason. There is just not enough information, that's why Carson is asking more details about your configuration. If you want to go to the bottom of this more troubleshooting is needed and as this is a quite specialist topic, TAC would be your best bet IMHO.

Are you saying that it is intended behavior to flood mDNS traffic to every client on a WAN, regardless of the user's role's VLAN assignment?

If Airgroup is disabled, I think it's really unlikely that the controller is replicating mDNS across VLANs.

Do you see the mDNS traffic replicated/originating from there? Also, it may be that if you have a WLAN with users in multiple VLANs, and you don't do broadcast/multicast filtering, the bc/mc traffic (which mDNS is) may be replicated through that. It can also be that another device is proxying that mDNS.

Also note that many devices, have moved to Bluetooth discovery and go outside of the WLAN.

It depends a bit on what you have exactly seen. If you can't find the issue, it may be good to work with TAC and find what's going on.

I don't "not want to enable" anything. I'm just trying to understand what is happening. It is definitely true that I have clients on the same SSID assigned to different VLANs based on role, and if it is expected that in such a configuration all clients will receive mDNS traffic from all VLANs, then I have learned something and the mystery is explained.

The solution of course is AirGroup, but I have been unable to get AirGroup to register certain mission-critical devices (older generation OneScreen interactive smart screens). We are currently on vacation, so I will try AirGroup once again and, if I can't get it working, I will contact TAC.

That is how WLAN/WPA works in the standard. There is a shared key for broadcast traffic for all clients on a specific (B)SSID, the GTK, as the idea of broadcast is that everyone should be able to see that traffic, and if clients on the same SSID are on different VLANs, all clients see broadcast traffic for all VLANs active on the SSID. In most situations this is not an issue, but it is with mDNS as well with IPv6 RA traffic, and probably other protocols.

The solution around that is broadcast filtering, Airgroup and BC/MC to unicast conversion; but it seems you don't want to enable that.

BTW, that this is causing your issue is pure speculation and one possible reason. There is just not enough information, that's why Carson is asking more details about your configuration. If you want to go to the bottom of this more troubleshooting is needed and as this is a quite specialist topic, TAC would be your best bet IMHO.

Are you saying that it is intended behavior to flood mDNS traffic to every client on a WAN, regardless of the user's role's VLAN assignment?

If Airgroup is disabled, I think it's really unlikely that the controller is replicating mDNS across VLANs.

Do you see the mDNS traffic replicated/originating from there? Also, it may be that if you have a WLAN with users in multiple VLANs, and you don't do broadcast/multicast filtering, the bc/mc traffic (which mDNS is) may be replicated through that. It can also be that another device is proxying that mDNS.

Also note that many devices, have moved to Bluetooth discovery and go outside of the WLAN.

It depends a bit on what you have exactly seen. If you can't find the issue, it may be good to work with TAC and find what's going on.