Exactly, these devices are specifically designed to be discoverable by LAN devices automagically so the only reason I could think of for putting them in their own subnet is if you specifically are trying to block that functionality (so random users on the LAN cannot cast to your devices).
I share my connection with a friend across the street and even I don't bother with that hassle.
One reason to do this is security. A botnet of chromecasts or whatever that can't reach your main lan seems like not a bad idea.
You might get similar security by creating a brouter using ebtables and keeping them on the same subnet but different port with your ebtables rules controlling your traffic
EDIT: to elaborate a bit
So, the first thing to do here is probably go ahead and put these devices on the same network, and then wireshark the interaction. Check what is needed to have devices establish a link etc.
Then, you physically move the devices to a different port on the router, and you bridge between the main LAN port and the AUX port. Set up ebtables on the bridge, and have explicit rules allowing just the "legit" traffic needed for the function of the devices. If your various devices do get infected/owned by someone else, they can really only pass "legit" traffic to your regular LAN through the ebtables.
I ran my network this way for a while, and it worked for the most part. Essentially, what I had was an IoT VLAN into which all chromecast, roku and similar devices were placed.
I'll say up front that while the end result allowed clients in LAN to cast to devices in IoT, certain things like chromecast audio groups wouldn't work reliably, and occasionally, the list of available chromecasts would come and go. Ultimately, I decided to go with what "just works", by tossing everything back into the LAN. I may return to this setup at some point because I'm stubborn, and it did teach me quite a bit about multicast and these clever devices.
Allowing clients on my main LAN to speak to the IoT VLAN required a handful of things:
avahi-daemon to allow SSDP between IoT and LAN
LEDE Firewall to allow communication between IoT and LAN and vice-versa
iptables to mangle TTL for multicast as it crossed IoT to LAN
My Firewall zones were set up as follows:
LAN -> WAN, IoT Accept for Input, Output and Forward
IoT -> WAN Accept for Input, Output and Forward
Traffic Rules were configured so that devices in IoT can fetch DNS and DHCP from the router itself:
IoT -> Router: DHCP
IoT -> Router: DNS
IoT -> ANY:5353
IoT -> LAN:1900
IoT -> LAN:5556-5558
IoT -> LAN/126.96.36.199/4
But wait, there's more! Because Chromecast blasts with a TTL of 1, it’ll die when it crosses a subnet. To get around this, I had a custom IPTABLES rule to keep that TTL up:
I can understand that you want to keep some devices on a separated network, that's fine. But then you have to manually open holes between those networks, because you do not really want them completely separated. It seems to me that this only makes things more complicated, and creates a false sense of security.
I may return to this setup at some point because I'm stubborn, and it did teach me quite a bit about multicast and these clever devices.
Sorry to resurrect this, but did you ever return to this to get it working? Would love to hear how you got it working if you did, in fact, manage it. I've got it 90% there: my Chromecasts are in 192.168.1.1/24. I'm trying to cast to them from 192.168.3.1/24. Occasionally, I can see them from 192.168.3.1/24, but they drop-off pretty quickly and I can rarely connect to them across the subnets.
I'll refrain from posting my set-up for now, just in case this topic is well-and-truly buried, but happy to share if there's anybody out there.
I did and have it working pretty well. The chromecast groups are still an issue across subnets, but things work for the most part. If your targets are appearing and then disappearing, you should check to see whether the avahi daemon is working. You'll also need to ensure the ttl value is modified as above.