Chromecast between vlans

[BCNetworkTeam]

Hello everyone !

I'm posting today because I did not find solutions to my problem, even after taking much time to search across the internet and the meraki's community forum.

We are actually using those devices :

Wireless AP : MR52

Access switchs : MS225-48FP

Core switchs : MS410-16

MX Firewalls : MX100

Here is the network diagram :

I've been asked to deploy a VLAN hosting chromecast TVs on our office network.

So today we have :

Office VLAN : ID 18 

Chromecast VLAN : ID 56

When I plug my computer on the chromecast VLAN, no problem, i'm able to cast.

The issue is when I want to cast from the office VLAN, my computer can't find the chromecast TV, even if i'm wired or on WIFI (on office VLAN 18).

I've tried different configurations but still not working.

From what I understood, we need to enable multicast routing on L3 interfaces (core switches), but I dont know if we need to set up a RP or IGMP snooping etc.

I'm not really used to Meraki's stuff.

Anybody got an idea about how to set ip up ?

Thanks for your help !

[BrechtSchamp]

I'm not sure if it's possible. But there are others with the same problem. Take a look at this topic:

https://community.meraki.com/t5/Security-SD-WAN/Routing-Chromecast-across-VLANs/m-p/36272?collapse_d...

[BCNetworkTeam]

Hi BrechtSchamp,
Yeah I saw this post too.
As far as I understood, MX series are not able to route multicast traffic.
But my multicast traffic is actually not going through those firewalls since VLAN 18 and 56 gateway are configured on the core switches.

I made some packet captures, and saw the multicast request going from my computer to the switch where the TV is connected.
But it's not being distributed to the TV's port.
I believe it's not being routed on the VLAN 56, the request is coming on the VLAN 18 I think.

[NolanHerring]

Do you have IGMP Snooping enabled?

[BrechtSchamp]

I don't think regular L3 multicast routing does the trick. According to what I've read the packets sent out by Chromecasts have TTL of 1 so they're not designed to be routed.

[NolanHerring]

Hmm...ya not sure if this is a limitation of Chromecast or Meraki.

From what I'm reading it uses mDNS (Bonjour Forwarding) which can be configured on the MX Firewall rules. Since he has all the L3 interfaces on the cores switches though, I'm not sure if there are any settings there for mDNS

[BCNetworkTeam]

Hey guys,

So i've called meraki's support, and they confirmed me multicast traffic will not be routed.

It's not something you can do actually with those devices.

But they told me that you can connect those chromecast TV to a separated WIFI network, and enable "bonjour" forwarding (even if I thought it was specific to Apple's devices).

With that way, it should work.

I'm gonna try it tomorrow, i'll keep you updated !

Thanks for helping !

[NolanHerring]

Yea so to me that seems like some sort of oversight.

Looks like Bonjour is on the MX and MR, not the MS. Seems lame if you ask me.

I think ironically then, if you had your SVI's for those two VLANs living on the MX, you could actually get it to work.

Might be worth testing just for general curiosity purposes and let us know ^_^

[PhilipDAth]

Get a Cisco WebEx Share - and you'll life will be much simpler.

https://www.cisco.com/c/en/us/products/collaboration-endpoints/webex-share/index.html

[m_Andrew]

I don't know this off the top of my head. Does anybody know how the device which acts as the Chromecast video source/sender actually sends the video traffic?

Bonjour / mDNS is just used for devices to "broadcast" services they offer onto the network, by sending periodic announcement packets to 224.0.0.251. Since that group is in the link-local control range, it will always get flooded in the VLAN from which it originated.

For example, printers may send mDNS announcement packets to 224.0.0.251. The contents of the packet is a message which says "I'm a printer and my IP is X.X.X.X".

In this way, any device on the network that receives this packet can automatically discover that the printer exists, as well as learning its IP, without any sort of user intervention required to manually configure it.

If a Chromecast device uses mDNS to announce something to the effect of "I'm a Chromecast streaming device, and I offer a set of multicast video feeds", even if this mDNS announcement is copied into another VLAN and devices in that VLAN learn that the Chromecast exists, they still wouldn't be able to get the multicast video stream if the video traffic itself is sent to a multicast group that's in the non-routable range (224.0.0.0/24) or has TTL=1. I'm not aware of any way this could directly get "routed" from one VLAN into another, even with Bonjour / mDNS forwarding set up in some capacity.

On the other hand, if the video stream itself is sent to a routable multicast group with TTL > 1, then the stream CAN get routed to a different VLAN. Alternatively, if the stream itself is not even multicast and is just a direct unicast stream sent to the receiving device, that too could be routed. 

[NolanHerring]

Good questions @m_Andrew 

I wonder if it would work if he enables Multicast Flooding

What I do know is on other forums (like UBNT forums) people are able to get it to work across multiple VLANs, so I would imagine it is 'doable', however it works.

[BrechtSchamp]

According to what I've read it indeed only uses mDNS for the discovery and then uses a unicast SSL connection between the Chromecast and the client device, and often another unicast connection to the actual source if it can be streamed directly.

So you just need a proxy or reflector that listens for the _googlecast._tcp.local. mDNS service string and forwards those to the correct vlan. Avahi is a keyword I came across a lot there. I'm not sure the bonjour forwarding in the MX and the MR do the trick as Chromecast doesn't seem to be listed.

After that you'll also need to open certain ports between the vlans to enable the actual communication following the discovery.

https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-mobility/119017-config-chromec...

[BlakeRichardson]

@PhilipDAth  at over $600 NZD Webex adaptor is very over priced and probably not economical for most users. 

[PhilipDAth]

I was in the board room of a large company once during a meeting.  The boardroom had a TV with a built in Chromecast.  All of a sudden it started playing porn.  They were very embarrased and had trouble stopping it.  The problem is anybody in the company on any of the floors could have been the ones casting to it.

WebEx Share uses audio to verify the person casting to it is in the same room.

I bet that company wished they had disabled Chromecast and had a WebEx share.

[BCNetworkTeam]

@NolanHerring About setting up SVI's on the MX, we asked to support if it could be a solution, and the awnser is no. MXs Appliances still not support multicast routing.

@PhilipDAth Not really my call but i'm gonna take a look at it. Could be a good suggestion to my management. Thanks for the info. And HOLY F*** thanks for sharing this story, made me laugh this morning, gonna be a good day 🙂

[NolanHerring]

---

@BCNetworkTeam wrote:

@NolanHerringAbout setting up SVI's on the MX, we asked to support if it could be a solution, and the awnser is no. MXs Appliances still not support multicast routing.

---

Call me crazy, but there are Bonjour Forwarding config options on the MX, so isn't that all for multicast stuff like AirPlay etc.?

[BCNetworkTeam]

@NolanHerring Well I had the same understanding, but Meraki's support told me to try bonjour forwarding over the APs.

Tried it, does not works. So even if "bonjour" is basically working with multicast, I think you can't really use it with other devices than Apples.

After talking with other network guys, we came to the conclusion that Chromecast devices are more personal home solutions, not really designed for business networks.

Also, funny thing we saw this morning, is the "guest" mode on chromecast TV. You can use it even when you cut off your WIFI, Bluetooth, mobile data etc on your phone.

First I though it was done by some old magic practices, but then I came across this article :

https://www.itpro.co.uk/mobile/28299/how-to-use-chromecast-without-wi-fi

Pretty interesting : 

Using Chromecast without Wi-Fi

The first thing you'll need to do is ensure your Chromecast is running the most up-to-date firmware. As we've mentioned, using your Chromecast without Wi-Fi will only work with the most recent software. 

This is because Chromecast now has something called guest mode. This enables Chromecast owners to open the devices to guests, without those users having to be connected to a Wi-Fi network. When an app that is Google Cast-ready is launched on a guest user’s mobile device, this device detects the presence of a special Wi-Fi beacon and shows the Cast icon within the application. When the Cast icon is tapped, casting to a ‘Nearby Device’ will be listed as an available option. 

The Chromecast device generates a random four-digit number that is required to cast to it using guest mode. When a device nearby tries to connect, the Chrome cast device transfers this four-digit number using short inaudible tones. Should audio tone pairing fail, a guest will then be given an option to connect manually by entering the 4-digit number displayed on the TV display and in the Chromecast app.

So to close this case, we are gonna suggest to management other way to use those TVs...

Thanks everyone for the contribution to this post !

[NolanHerring]

You are indeed correct that Chromecast is not a business related device. However to be fair, Bonjour was created specifically because people kept using non-business devices, like AppleTV and other products, in the enterprise, so it was created specifically for those use-cases.

I know I have seen others get it to work on other network gear (UBNT for example). There is some sort of LAN adapter for them as well, but I think your best bet is to find something else 😃

Good luck !

[m_Andrew]

I'm just thinking out loud here. From the discussion, it sounds like the architecture of Chromecast is something as follows:

(1) Chromecast video source device sends mDNS/Bonjour announcements to 224.0.0.251 that identify itself as a source for some particular feed(s).

(2) A Chromecast receiver device watches for these announcements. When it picks one up, it learns of the Chromecast source and then can establish a unicast connection to the video source.

If the video stream is unicast, it can easily be routed across multiple layer 3 hops. But the funny thing is the mDNS announcement packets are *not* routable, being in the 224.0.0.0/24 control range. So even though the video stream itself can be routed, no device outside the direct L2 domain of the mDNS announcements can ever learn about it unless some hack is running on the network to copy the mDNS packets from one VLAN and inject them into another.

The configuration of unknown multicast flooding will not be relevant here either. Switches that perform IGMP snooping never perform any snooping or filtering for multicast destinations inside of 224.0.0.0/24. So regardless of whether 224.0.0.251 is considered to be known or unknown, it will always flood the same as a broadcast within a VLAN, just like a DHCP Discover or ARP request.

If this is all true, there's one seemingly easy modification that could be done to the Chromecast architecture to address this:

Instead of using Bonjour/mDNS announcements sent to 224.0.0.251 for service discovery, the announcement packets could simply be sent to a different multicast group that *is* routable. For example, instead of 224.0.0.251, 225.0.0.251 could be used instead. Or almost any other unused multicast group which is *not* in the 224.0.0.0/24 scope.

This would permit the announcement packets to route across L3 boundaries, provided multicast routing has been enabled, and it would not require hacks to just copy the packet from one VLAN and inject it into another (which is basically how "Bonjour forwarding" operates).

The main downside with an approach like this that I can see would be that it would no longer interoperate with other endpoints using mDNS, which are still only monitoring for announcements on 224.0.0.251. However, in this case it does not seem relevant. I'm presuming that Chromecast is somewhat of a closed system: Google defines how the senders work and how the receivers work. So it would be trivial to modify the application such that senders and receivers use and expect service announcements on a group other than 224.0.0.251.

It's also very possible that a caveat exists which I haven't considered... I would not call myself an expert with the inner workings of Chromecast. 

[Mikael_Lindgren]

Yeah, you are essentially correct Brecht. I'll make an attempt to explain this in my own words for anyone that needs clarification: 
Depending on the mDNS-device (Apple-TV, Chromecast, etc, i will use all these names varyingly depending on what i feel best explains what i mean) the usual way it works is that the mDNS-device multicasts it's capabilities on the broadcastdomain/VLAN (TTL1) with a service-string (ex: _googlecast._tcp.local.). If you are lucky (or very knowledgeable before buying the devices) it is a generally accepted service-string that is the same no matter which device you plug in. If you are unlucky it is a device-unique service-string (_9967AQ0s243._sub._googlecast._tcp.local.), the "lucky" part will be explained below.

Now, i haven't actually seen this config on Meraki and can't really tell you about that, but since its "Cisco" it should be similar to other Cisco WLCs (Cisco has made their WLCs into mDNS-proxies):

-first you need to make a mDNS-profile; Cisco Provides a default with the most common services but that default might not include all the service-strings your mDNS-devices broadcasts. Either read the documentation on the mDNS-device and add any mentioned service-strings, or sniff the chromecast-VLAN for all mDNS-broadcasts and make a list of offered service-strings. The Standard Chromecast servicestring is "_googlecast._tcp.local." or "_chromecast._tcp.local." but it depending on vendor (my experience it's usually the "Smartboard"-vendors that does this) it might be "VendorArbitrarilyChosenUniqueIDForThisSpecificDevice._tcp.local" (this basically means you need to add exactly every devices specific string intead of just "_googlecast._tcp.local").

-you then activate mDNS (bonjour IGMP sniffing) on the WLAN Profile and specify what profiles to use for sniffing service-strings ("the one you made" or "default").

-you then go to one of the APs on the site where you have the Chromecasts and want to provide this mDNS-device service and configure it to sniff in a specified VLAN (klick the AP, go to "advanced", mark "mDNS-snooping" and then specify what VLANs the mDNS-devices are in)
-go to the switch that this AP is connected to and make the switchport into a trunk with both the management-VLAN and the mDNS-Device-VLAN. 

-Now the accesspoint can sniff for the services on the mDNS-VLAN and populate a global list of available services in the WLC.

-when a wireless device now wants to use these services it will make a mDNS-query on wifi and depending on how the controller is configured the controller will provide the client with the list (default it will send the whole list which might include services on other sites which isn't really a favorable thing).

-to limit the list of devices that the controller returns to querying clients you need to make a mDNS-policy in WLC and fill that list with the source MAC-addresses of the Chromecast-devices and then apply that list to either a specific AP (meaning only clients connected to that specific AP will get the list) or to an AP-group (meaning if the client is connected to an AP in the AP-group it ill get the list).

that covers the signaling part of mDNS. 

-now the client knows of the available mDNS-services on the network, it will now try to contact the device for use. Depending on the mDNS-device this will be either by Unicast or by Multicast. This is in my experience usually default Unicast-SSL which is why i upvoted BrechtSchamp 🙂 (For the specific services of Chromecast/Apple-TV/Airprint/AirPlay, etc, it doesn't make sense to make the streaming part of the device into Multicast, if the mDNS-device was a camera or a monitoring tool with several client-monitors showing the same thing it would make more sense to use Multicast for the streaming part) 

-Unicast method means that the client will be routed through the network to the chromecast and everything should work as peer-to-peer communication (i.e. if it is the same vrf, you are already done configuring). If you have a firewall separating the "office network" from the "Chromecast network" you need to make sure that the client is allowed to contact the Chromecast through the firewall (chromecast uses ports usually ranging UDP/32768-61000 and TCP/8008-8009). For Apple-TV or other mDNS-devices it might be other ports and you need to sniff the traffic or google the used ports for that specific mDNS-device. 
-if it uses multicast traffic for transporting streaming/data you will first need to make sure that your network supports Multicast routing and then also make sure that the traffic is allowed through any firewalls that separates the networks.

I hope this helps clarify for anyone new to mDNS.

/Mike

[KaylaEik]

A company I used to work for, we ran into this issue frequently when we were coming up with wireless solutions at Greek houses.  Holy cow, was it a nightmare.  It sounds like you were given an answer about multicast traffic not being routed, which is what we found out, but it would be nice to find a way for this to work the way we want it to.  

[PhilipDAth]

@BCNetworkTeam ,

"Tried it, does not works. So even if "bonjour" is basically working with multicast, I think you can't really use it with other devices than Apples."

This does work, but people often miss the caveat that the wired VLAN being used can not be the native VLAN - which is usually VLAN1.  This aspect is critical.

https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/Bonjour_Forwarding

"Please note that the service VLAN cannot be the native untagged VLAN, which is usually 1. "

So if you are using MR, put your Chromecast on a VLAN other than the native VLAN - and you'll be away.

[m_Andrew]

On top of that it should be just as easy to leverage Bonjour forwarding on an MX -- even if the MX is not being used for routing.

The only requirement here would be you would need to define each VLAN on the MX which contains the target mDNS announcers and mDNS consumers. With the VLANs defined you could then add the Bonjour forwarding configuration for these VLANs directly on the MX, just as long as these VLANs are trunked up to the MX from the downstream LAN infrastructure.

Although you'd end up creating potentially unused VLAN interfaces on the MX it should be totally harmless, just make sure DHCP is turned off for those VLANs.

[BrechtSchamp]

The question I had about that is whether the MX will forward any mDNS packets or only the ones in the list (when you select all services):

-AirPlay

-Printers

-AFP

-Scanners

-iChat

[MatsLarson]

---

@BrechtSchamp wrote:

The question I had about that is whether the MX will forward any mDNS packets or only the ones in the list (when you select all services):

-AirPlay

-Printers

-AFP

-Scanners

-iChat

---

It works with 'All services' selected, but I'd be interested in a list of exactly what ports/ranges etc each option actually entails, or the option to set something custom to allow ~only~ the Chromecast traffic.

[CharlesIsWorkin]

Hey dudes, 

has anyone gotten this to work? How did ya'll do it?

I enabled Bonjour forwarding to a media vlan, and I'm not finding my Chromecast TV's. The vlan they are on is Bridged, and they are wired clients on an MS-220.

[CharlesIsWorkin]

I forgot about this. 🙂 https://documentation.meraki.com/MX/Other_Topics/Configuring_Bonjour_forwarding_for_the_MX_Security_...