Local Switching, mDNS Snooping and Chromecast

[Dorian Kind]

Hello everyone,

we have a Cisco WiFi setup at our company constisting of one WLC (2504) and 5 access points, 4 of which are in the main office and one at a remote location (connected via an IPsec tunnel). The remote AP is configured to FlexConnect mode, and we have set up a staff WLAN using 802.1X auth and local switching. So far, everything works perfect.

However, we now want to support Chromecast devices in our wireless network. I have setup a new WLAN with WPA2-PSK authentication for those devices, added the "Googlecast" entries to the mDNS profile and activated mDNS Snooping on this WLAN. This appears to be working as well, at least I can see the corresponding entries in the mDNS -> Domain Names tab (Chromecast switched from multicast/SSDP to mDNS recently).

However, clients in the staff WLAN are not able to see the devices. My guess is that I would need to also activate mDNS snooping on the staff WLAN, but of course this is not possible because of local switching being enabled.

I tried to create two different AP groups, one for the local APs and another for the remote one. Then I duplicated the staff WLAN, with the idea of deploying one copy on the local AP group with local switching disabled and mDNS snooping enabled and the other copy on the remote AP group, enabling local switching and disabling mDNS snooping. My idea was that this would allow the employees at the local office to use the Chromecast devices, but unfortunately it's not possible to configure two WLANs with the same SSID and L2 security, even if they're not on the same AP / AP group.

Another solution would just be to create a separate WLAN for the remote AP, but that would require to push another profile and inevitably result in confused employees when they first visit the remote branch.

Is there any way to make our Chromecasts work while still using the same WLAN for both locations? Any pointers are greatly appreciated.

[Sebastian Helmer]

I'm not 100%sure about the details and why that works this way. But u can create two SSID as long as u use an ID higher than 16. So start at 17 and it works, maybe that has something to do with the default group they will not belong to..

comming back to your 2504...I see no way to use an ID above 16 because that's the max it supports.

So, please have a look at that Guide for Chromcast, as I run through i see that it hase maybe nothing to do with mDNS..

http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/7-6/chromecastDG76/ChromecastDG76.html

Br,

Sebastian

pls. rate if helpful

[Dorian Kind]

Hi Sebastian,

thanks for your feedback. As you mentioned, with the 2504, this does not seem to be possible unfortunately.

I had taken a look at the guide you linked to previously; regrettably the discovery mechanism for Chromecast changed from SSDP to mDNS, so that document is not directly applicable anymore.

Best regards,
Dorian

[ajc]

Hi Dorian,

Any update on this case?. I am having the same issue. I enabled globally on the WLC multicast and Chromecast works fine. BUT, we do not want that because our current Aiplay is working without the Multicast option configured. mDNS like you said is quite enough for Apple TV/Bonjour config.

I disabled Multicast but nothing can be mirrored.

thanks

[Dorian Kind]

Hi Abraham,

unfortunately no. As far as I understand it is not possible to enable both local switching and mDNS snooping on the same WLAN. We've given up on the Chromecasts and plan to see whether we can get AirTame to work as those devices seem to support connecting directly via IP address / hostname.

Cheers,
Dorian

[ajc]

Hi Dorian,

Long time since last note. Any success with the  Airtame? I just got a request about using that device on our WiFi environment so I would appreciate any feedback from your side.

thanks

[Andrii Oliinyk]

Hi

have u managed Airtame working on your network in aspects relevant to mDNS?

[Airtame_Dave]

Hi there!

You can use both SSDP and mDNS to discover Airtames in your network.  However, your network needs to be configured to support it.

Because of how multicast messages traverse a network, I highly recommend creating a separate VLAN for your Airtames.
Do your VLANs terminate on your WLC, firewall and/or your core network?  Your answer to this question should point you to how you should configure multicast.

If the Airtame VLAN, your internal user VLAN and your guest user VLAN terminate on the same appliance, you'll need to enable IGMP on your Airtame VLAN interface (SVI) and configure Protocol Independent Multicast (PIM) in dense mode.  This negates the need for a rendezvous point (RP) and allows multicast traffic to leave the broadcast domain. The VLANs that you would like to receive those multicast messages will need their VLAN interfaces configured to use IGMP and PIM.

It's quite common to see an internal user VLAN terminate on a core network and the guest network to either terminate on the WLC or perhaps a firewall. If your network is designed this way, creating a VLAN for your Airtames which terminates on the firewall gives you the option to allow access to the Airtame devices from both your internal and guest networks.  You'll just need to make sure the rule base in the firewall is configured to allow traffic on the correct TCP and UDP ports to and from the Airtame VLAN from the respective VLANs for your internal and external users.

In an Airtame deployment where you have VLANs configured on separate layer 3 devices, the Airtame VLAN SVI needs to have IGMP enabled as well as PIM in Sparse Mode in order to ensure that the multicast messages reach your internal users connecting through your core network.  In order for PIM Sparse Mode to work, you'll need to configure a rendezvous point (RP) on the Airtame SVI to tell the interface where to send multicast traffic. 

Typically, you'll find 2 or more physical connections between your firewall and the core network.  One connection for the layer 2 traffic and one connection for your layer 3 traffic.  The RP IP address to be configured on the Airtame SVI in this scenario will be the IP address of the layer 3 interface on the core network which is physically connected to your firewall.

Many appliances from different vendors handle multicast traffic differently with features which could be unique to the appliance.  So be sure to check the admin guides to your equipment to see what's available to you.

If you run into any trouble with setting this up, reach out to the Customer Success Team on Airtame's website and they'll be more than happy to assist you. 

[Andrii Oliinyk]

Hi Dave

our customer requested us to support his Airtame PoC. Customer requested us to implement inter-VLAN/inter-VRF MC-routing for the group 224.0.0.250. 224.0.0.250 group is broadcast-domain-limited & cannot be even inter-VLAN forwarded. How does this limitation impacts overall deployment?