Bonjour, 5508 WLC, mDNS and pain

[andrewburridge]

Hi Guys.

I am having a few issues getting Airplay to work through a 5508 WLC. Here's the summary of my situation:

- 5508 WLC, software version 7.4.121.0

- Topology is fairly simple

Wireless Client -----> AP in Local Mode broadcasting SSID tagged to VLAN 301 ------> WLC with SVC in VLAN 301 -------> L2 Switch with VLAN 301 -------> Airplay Server wired into VLAN 301

Now my understanding is that as this is effectively an L2 setup constrained to VLAN 301 I shouldn't necessarily need multicast or mDNS in this situation. Is this a valid assumption?

Regardless, this setup doesn't work. I have followed the relevant configuration guides for mDNS in case I required this on the controller, but this still doesn't result in the Airplay function appearing on the client.

At the moment, the mDNS profile Apple-Protocols is configured to include 3 services:

_airplay._tcp.local.
_raop._tcp.local.
_antares._tcp.local.

And is applied to the WLAN and to the controller SVI in VLAN 301.

When debugging mDNS, I see that the phone requests and appears to be sent responses for the 3 services that I'm trying to get working:

*Bonjour_Msg_Task: Jan 13 10:19:57.749: 9c:fc:01:1c:04:e2 Parsing 2 bonjour Questions.
*Bonjour_Msg_Task: Jan 13 10:19:57.749: 9c:fc:01:1c:04:e2 Query Service Name: _airplay._tcp.local., Type: C, Class: 8001.
*Bonjour_Msg_Task: Jan 13 10:19:57.749: qNameStr:_airplay._tcp.local., bonjServiceNameStr:_airplay._tcp.local., bonjSpNameStr:_airplay._tcp.local.
*Bonjour_Msg_Task: Jan 13 10:19:57.749: Service Name:_airplay._tcp.local. is supported in Master-service-db, Name: AppleTV
*Bonjour_Msg_Task: Jan 13 10:19:57.749: 9c:fc:01:1c:04:e2 Service:_airplay._tcp.local. is supported by client's profile:Apple-Protocols
*Bonjour_Msg_Task: Jan 13 10:19:57.749: Sending Bonjour Response
*Bonjour_Msg_Task: Jan 13 10:19:57.749: Service Provider Name: , Msal Service Name: AppleTV
*Bonjour_Msg_Task: Jan 13 10:19:57.749: Sending Query Response bonjSpNameStr: , bonjMsalServiceName: AppleTV, bonjourMsgId:0, dstMac: 9C:FC:01:1C:04:E2 dstIP: 10.0.122.254
*Bonjour_Msg_Task: Jan 13 10:19:57.749: vlanId:301, allvlan:0, isMcast:0, toSta:1
*Bonjour_Msg_Task: Jan 13 10:19:57.749: 9c:fc:01:1c:04:e2 Successfully sent response for service: _airplay._tcp.local..

*Bonjour_Process_Task: Jan 13 10:19:57.750: Inside buildBonjourQueryResponsePld, available_len =1365
*Bonjour_Process_Task: Jan 13 10:19:57.750: Found SpData: MyMedia._airplay._tcp.local.
*Bonjour_Process_Task: Jan 13 10:19:57.750: Transmitting bonjour Pkt to STA: 9C:FC:01:1C:04:E2

*Bonjour_Process_Task: Jan 13 10:19:57.750: Unicast Packet sent to client 9C:FC:01:1C:04:E2 success.

*Bonjour_Msg_Task: Jan 13 10:19:57.749: 9c:fc:01:1c:04:e2 Query Service Name: _raop._tcp.local., Type: C, Class: 8001.
*Bonjour_Msg_Task: Jan 13 10:19:57.749: qNameStr:_raop._tcp.local., bonjServiceNameStr:_raop._tcp.local., bonjSpNameStr:_raop._tcp.local.
*Bonjour_Msg_Task: Jan 13 10:19:57.749: Service Name:_raop._tcp.local. is supported in Master-service-db, Name: AirTunes
*Bonjour_Msg_Task: Jan 13 10:19:57.749: 9c:fc:01:1c:04:e2 Service:_raop._tcp.local. is supported by client's profile:Apple-Protocols
*Bonjour_Msg_Task: Jan 13 10:19:57.749: Sending Bonjour Response
*Bonjour_Msg_Task: Jan 13 10:19:57.749: Service Provider Name: , Msal Service Name: AirTunes
*Bonjour_Msg_Task: Jan 13 10:19:57.749: Sending Query Response bonjSpNameStr: , bonjMsalServiceName: AirTunes, bonjourMsgId:0, dstMac: 9C:FC:01:1C:04:E2 dstIP: 10.0.122.254
*Bonjour_Msg_Task: Jan 13 10:19:57.749: vlanId:301, allvlan:0, isMcast:0, toSta:1
*Bonjour_Msg_Task: Jan 13 10:19:57.749: 9c:fc:01:1c:04:e2 Successfully sent response for service: _raop._tcp.local..

*Bonjour_Process_Task: Jan 13 10:19:57.750: Inside buildBonjourQueryResponsePld, available_len =1365
*Bonjour_Process_Task: Jan 13 10:19:57.750: Found SpData: D4AE52D49875@MyMedia._raop._tcp.local.
*Bonjour_Process_Task: Jan 13 10:19:57.750: Transmitting bonjour Pkt to STA: 9C:FC:01:1C:04:E2

*Bonjour_Process_Task: Jan 13 10:19:57.750: Unicast Packet sent to client 9C:FC:01:1C:04:E2 success.

*Bonjour_Msg_Task: Jan 13 10:20:52.919: 9c:fc:01:1c:04:e2 Parsing 1 bonjour Questions.
*Bonjour_Msg_Task: Jan 13 10:20:52.919: 9c:fc:01:1c:04:e2 Query Service Name: _antares._tcp.local., Type: C, Class: 8001.
*Bonjour_Msg_Task: Jan 13 10:20:52.919: qNameStr:_antares._tcp.local., bonjServiceNameStr:_antares._tcp.local., bonjSpNameStr:_antares._tcp.local.
*Bonjour_Msg_Task: Jan 13 10:20:52.919: Service Name:_antares._tcp.local. is supported in Master-service-db, Name: Bonjour Browser
*Bonjour_Msg_Task: Jan 13 10:20:52.919: 9c:fc:01:1c:04:e2 Service:_antares._tcp.local. is supported by client's profile:Apple-Protocols
*Bonjour_Msg_Task: Jan 13 10:20:52.919: Sending Bonjour Response
*Bonjour_Msg_Task: Jan 13 10:20:52.920: Service Provider Name: , Msal Service Name: Bonjour Browser
*Bonjour_Msg_Task: Jan 13 10:20:52.920: Sending Query Response bonjSpNameStr: , bonjMsalServiceName: Bonjour Browser, bonjourMsgId:0, dstMac: 9C:FC:01:1C:04:E2 dstIP: 10.0.122.254
*Bonjour_Msg_Task: Jan 13 10:20:52.920: vlanId:301, allvlan:0, isMcast:0, toSta:1
*Bonjour_Msg_Task: Jan 13 10:20:52.920: 9c:fc:01:1c:04:e2 Successfully sent response for service: _antares._tcp.local..

*Bonjour_Process_Task: Jan 13 10:20:52.920: Inside buildBonjourQueryResponsePld, available_len =1365
*Bonjour_Process_Task: Jan 13 10:20:52.920: Found SpData: Antares._antares._tcp.local.
*Bonjour_Process_Task: Jan 13 10:20:52.920: Transmitting bonjour Pkt to STA: 9C:FC:01:1C:04:E2

*Bonjour_Process_Task: Jan 13 10:20:52.920: Unicast Packet sent to client 9C:FC:01:1C:04:E2 success.

My next step (I'm remote from this site) is to actually run some packet captures on clients and use a Bonjour browser to discover whether the traffic is actually hitting the client. If it's the case that the traffic isn't actually hitting the client, then ruling out packet loss, are there any configuration reasons on the WLC why this traffic wouldn't go down the CAPWAP tunnel?  Alternatively, is there something fundamentally wrong with the way I've understood this process?

N.B., when connecting a simple AP directly to the L2 switch, this works as expected, so I know that it's working before it's being parsed by the controller.

Any ideas would be greatly appreciated.

Thanks.

[Freerk Terpstra]

Any multicast and broadcast traffic is being blocked at the WLC by default, this behavior is different comparing with autonomous and flex-connect access-points as you already experienced. So yes, you need to enable multicast globally for multicast traffic to flow. Next you have to options how to transport the encapsulated multicast client traffic from the WLC to the access-points: unicast or multicast mode. You can imagine that with a lot of multicast traffic it is more efficient to use multicast mode. Doing it with unicast can be a heavy task for the WLC, because of this the 2504 has no other option than multicast mode. If the traffic needs to be routed you need to make sure multicast routing is enabled on the LAN side.

For mDNS to work "mDNS Global Snooping" needs to be enabled with query's enabled for the specific services as well. For what I have seen is is also required to add the "AirPrint" services if you want to use AirPlay. Also make sure that you add the specific mDNS profile to the wired interface besides the SSID.

Last but not least I recommend you looking at this CiscoLive presentation about mDNS. Gives good understanding about what is going on and has a lot overlap with AirOS's implementation.

Please rate useful posts... :-)

[andrewburridge]

Thanks for the reply Freerk.  What you outline makes sense.

The Cisco Live presentation is interesting, but it deals with Bonjour services across subnet boundaries, which is something that I don't need to accomplish.

I guess my question can be condensed to a less rambling on than my initial one above. :)  Is my summary below correct?

As the traffic is all taking place inside the same subnet, I shouldn't need to configure mDNS snooping on the WLC.  I will however need to configure multicast on the WLC and make a decision about whether to forward as unicast or multicast.

Thanks.

[andrewburridge]

Just for the sake of completion, I have resolved my issues.

I needed to enabled multicast, IGMP snooping and set the multicast mode to unicast to get this to work.  This isn't ideal, but in my deployment this shouldn't cause too many issues.

I simply couldn't get it to work when doing multicast to multicast.  The controller was identifying the multicast traffic coming in from the Apple TV and giving it an MGID, but when doing a packet capture on the client side I never saw any multicast traffic coming in from the controller.  The second I switched the mode to multicast to unicast, everything kicked into life.

Hopefully this is of some use to somebody!

[Yevhenii Petrov]

Hi All!
A few notes if you do not mind
For bonjour you do not need enable multicast. Multicast and bonjour was divide in 7.4

"From 7.4 release, WLC supports bonjour gateway functionality on WLC itself for which you need not enable multicast on the controller. The WLC will snoop all bonjour discovery packets and will not forward the same on AIR or Infra network"

http://www.cisco.com/c/en/us/td/docs/wireless/technology/bonjour/7-5/Bonjour_Gateway_Phase-2_WLC_software_release_7-5.html#pgfId-44269

Then you enable multicast you allow this traffic only for vlan301 between wireless and wired domains. If you will need to allow access to this service for clients from different vlan - this will not work. For pass mDNS between vlans  you need to use "bonjour gateway"

In addition you can try to use default mDNS profile. Some of apple services may be linked.
Try to disable peer-to-peer. Note what it does not need for multicast.

https://supportforums.cisco.com/document/12544606/appletv-and-airplay-does-not-work-unless-p2p-allowed
 
In general this is a big problem with documentation about subject.
There is several guides with not entirely clear phrases and simple implementations.
So I absolutely agree with name of your subject :)