There are many questions on using a Chromecast or AirPlay devices (like the new Sonos devices with Airplay2) on a different VLAN.  First of all, I think it is a good habbit to put all your IoT devices in a separate VLAN since it’s easier to manage, protect/secure and isolate.;

  • IoT devices often use a lot of broadcasts/multicast you don’t want on your workstation LAN.
  • IoT devices might not get frequent updates and sit several years with old firmwaress, this implicated a possible security risk.
  • You probably want to limit IPv6 to your IoT vlan, having all your devices automatically getting an IPv6 address and being accessible from the internet is not a good idea, especially not with those old kernels ;)
  • You don’t want to give anyone who comes in your house or even your kids, access to your Roomba, Philips HUE, Sonos, Chromecasts, lawn robot, etc.

First, let’s set up a default VLAN seperation:

  • VLAN1 – Normal/Default VLAN with Workstation(s) and iPhone/iPad
  • VLAN4 – IoT
  • VLAN11 – Guests (for WiFi Guests)

When having multiple VLANs, we do however want to access the Chromecast and AirPlay from our VLAN1. There are 2 issues we are dealing with:

  1. Multicasts
  2. mDNS

Both techniques do not travel across VLANs. There were some people setting up a mDNS reflector like AVAHI and connecting their VLANs (even on Hyper-V), but since the new Cisco IOS 15.2, that’s not needed anymore!

Cisco > IOS 15.2 now offers an mDNS gateway, that in combination with their pim sparse-dense technique, makes it very easy to finally use a Chromecast on a different VLAN.

Example:

Switch#
.....
service-list mdns-sd REDISTRIBUTE-IOT-MDNS permit 10
  match message-type query
!
service-list mdns-sd REDISTRIBUTE-IOT-MDNS permit 20
  match message-type announcement
  match service-type _googlecast._tcp.local
!
service-list mdns-sd REDISTRIBUTE-IOT-MDNS deny 30
!
!
service-list mdns-sd QUERY-IOT-MDNS permit 10
  match message-type query
!
service-list mdns-sd QUERY-IOT-MDNS deny 20
!
!
service-list mdns-sd PERMIT-ALL permit 10
!
!
interface Vlan1
  ip address 192.168.0.1 255.255.255.0
  description Default VLAN for Workstations and your iPhone/iPad
  service-routing mdns-sd
    service-policy QUERY-IOT-MDNS IN
    service-policy PERMIT-ALL OUT
ip pim sparse-dense-mode
!
interface Vlan4
  ip address 192.168.4.1 255.255.255.0
  description IoT VLAN with Chromecasts and Sonos Airplay2 devices
  service-routing mdns-sd
    service-policy REDISTRIBUTE-IOT-MDNS IN
    service-policy PERMIT-ALL OUT
ip pim sparse-dense-mode
!
interface Vlan11
 ip address 172.16.0.1 255.255.255.0
 description Guest VLAN for Wireless guests
!

How does it work?
As you can see we made 3 service-lists and bind them to the two interfaces. In that way, we allow or deny specific mDNS traffuc between these interfaces:

  1. On the default/workstation VLAN, when you search for a Chromecast, it will actually do an mDNS query, this query is seen by the Cisco switch and put in a special database: ‘Cisco internal service gateway’.  In the above configuration, we only allow mDNS queries into this database: QUERY-IOT-MDNS IN
  2. On the IoT VLAN, we have to output/send this query (which was send from your workstation or iPhone), so from this ‘Cisco internal service gateway’ it needs to send out: PERMIT-ALL OUT
  3. The answer/announcement is saved in the service gateway Cache / database (more about this later).
  4. Once the Chromecast receive this mDNS query, it will answer using an mDNS answer/announcement. So on the IoT VLAN, we need to accept specific announcements to the service gateway: REDISTRIBUTE-IOT-MDNS IN
  5. On the default/workstation VLAN we need to output this answer: PERMIT-ALL OUT

To add support for Sonos/Airplay2, extend the above example:

Switch#
.....
service-list mdns-sd REDISTRIBUTE-IOT-MDNS permit 10
 match message-type query
!
service-list mdns-sd REDISTRIBUTE-IOT-MDNS permit 20
 match message-type announcement
 match service-type _googlecast._tcp.local
!
service-list mdns-sd REDISTRIBUTE-IOT-MDNS permit 30
  match message-type announcement
  match service-type _airplay._tcp.local
!
service-list mdns-sd REDISTRIBUTE-IOT-MDNS permit 40
  match message-type announcement
  match service-type _raop._tcp.local
!
service-list mdns-sd REDISTRIBUTE-IOT-MDNS deny 50
!
!
service-list mdns-sd QUERY-IOT-MDNS permit 10
 match message-type query
!
service-list mdns-sd QUERY-IOT-MDNS deny 20
!
!
service-list mdns-sd PERMIT-ALL permit 10
!
!
interface Vlan1
ip address 192.168.0.1 255.255.255.0
description Default VLAN for Workstations and your iPhone/iPad
service-routing mdns-sd
service-policy QUERY-IOT-MDNS IN
service-policy PERMIT-ALL OUT
ip pim sparse-dense-mode
!
interface Vlan4
ip address 192.168.4.1 255.255.255.0
description IoT VLAN with Chromecasts and Sonos Airplay2 devices
service-routing mdns-sd
service-policy REDISTRIBUTE-IOT-MDNS IN
service-policy PERMIT-ALL OUT
ip pim sparse-dense-mode
!
interface Vlan11
ip address 172.16.0.1 255.255.255.0
description Guest VLAN for Wireless guests
!

Also notice that on the VLAN1 and VLAN4 interface, there is the ip pim sparse-dense-mode command, I will not explain that this post, in short: It is for multicast traffic traveling between the 2 VLANs.

Once you have configured the above, you can add the following (query type) service-list:

service-list mdns-sd ACTIVE-QUERY-CHROMECASTS query
  service-type _googlecast._tcp.local

and let the Cisco router query the Chromecasts every 110 seconds:

service-routing mdns-sd
  service-policy-query ACTIVE-QUERY-CHROMECASTS 110

The advantage of this is that the internal service gateway has always up-to-date info on the Chromecasts (when it is turned on/off), so the cache of this internal service gateway can immediatelly respond to a query of your iPhone asking if there are any Chromecasts.