Re: Chromecast Para Windows
Abele Beardsley
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.
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.
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.
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.
@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
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.
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.
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.
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.
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 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.
-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).
-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.
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.
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.
d3342ee215