I’m having absolutely no success with getting chromecast to work. Read the entire thread, followed posted examples, not working
First question which may answer why its not working: Does all multicast traffic need to be in the same ‘bridge’ for PIM or IGMP Proxy to work?
I’ve been testing with a lab router using a more appropriate config for the actual environments i’d want to use this in, which is a more complicated topology that isn’t just VLAN’s on a single bridge. They’re either 1 or more physical interfaces or multiple bridges
Theoretically I don’t see why it should matter, yet its just not working
Here is the full config of a simple hAP AC2 lab (ROS v7.11.2) used for testing purposes, with topology as follows
ether2 and wlan2 are in bridge1 (this is where the chromecast is connected)
ether3 and wlan3 (virtual AP on wlan2) are in bridge2 (this is for testing multicast routing, connect phone here)
As expected everything works properly when connected to wlan2/mcasttest_1 as its in the same L2 segment
when joining wlan3/mcasttest_2 then can’t see the chromecast
Have also tried IGMP Proxy instead of using PIM which also does not work and have no success
You’re violating the Linux DSA network stack by having multiple bridges. Multiple bridges is a concept that has been depreciated with the introduction of VLAN aware bridging, migrate to proper single bridge configuration. Your topology is improper if you can’t do it with single bridges and VLAN awareness.
Have used multiple phones and found this to be woefully unreliable, some it works and others it just does not work whatsoever. Multicast routing itself seems to work but evidently multicast routing alone its not the only thing required for chromecast streaming to work 100% of the time (am testing with other multicast software which is working no issue). The chromecast just does not show up the majority of the time with most devices unless situated on the same L2 segment (in which case it works flawlessly)
mDNS Repeating would absolutely be a worthwhile implementation, as using Avahi to do mDNS repeating instead of multicast routing then it does actually work as expected. The real ‘problem’ is googles home based implementation that is hell bent on not working with any sort of corporate network, as evident by having a TTL of 1 on its discovery protocol.
The way I see it mDNS repeating is a good solution to a problem that exists in the real world). This is how other vendors have made it work and it solves the issue in a reliable way
I really wouldn’t worry about it, if there is a valid use case (practical management is absolutely a viable one) then by all means use multiple bridges. If its just a home based setup with multiple VLAN’s sure single bridge is a good idea. However as with everything it depends on the use case. Often it can be more practical and sensible to just use more than 1 bridge, i.e. template based configurations with varying topologies. When your physical port assignments vary greatly then it makes more sense to put Firewall/DHCP/Addressing/etc onto a bridge interface, then assign ports to that bridge as required. If the goal is network segregation and the traffic is still hitting the CPU anyway then it arguably doesn’t matter
If you setup to specific interfaces you need to move all the relevant entries around constantly on every deployment, and if you need need i.e. 2 physical ports in the ‘Staff A’ network and 3 in the ‘Services B’ network (both untagged and/or with overlapping VLAN numbers) at the location of the router, then you either need to add physical switches just to break out those extra ports or setup VRF’s. If it makes you feel all warm and fuzzy go for it, but if simply using multiple bridges makes everything simpler, easier to read/visualize/troubleshoot and still accomplishes the same result, by all means use multiple bridges
And yes zero issues with an empty bridge as a loopback interface. There are bigger problems in the world to worry about
Loopback is fine, I have single bridge for physical ports/LACP/The works, and separate bridge with STP disabled for loopback.
But in some cases, such as MPLS/VPLS use-cases, you might be forced to use two bridges for physical ports, VPLS tunnels, but still, if you use VLAN filtering, single bridge should be enough for all possible use-cases that rely on Ethernet standard.
In the future, when Ethernet is surpassed by something else, the story may differ.
I see another user here, is not well versed with Linux netfilter and Linux DSA
A lot of these people came from Unix/BSD oriented pf networking such as traditional Cisco, Juniper etc, that dates back to the early 90s and 2000s, where you can have multiple IRBs aka Linux bridge alternative with no problem as long as the specific hardware model is designed with an ASIC that can carry said multiple IRBs.
The same people proactively refuse to educate themselves on Linux Netfilter framework and DSA from scratch and catch up to modern-day 2023 networking where even Cisco’s IOS variants and Juniper’s Junos Evolved is 100% Linux.
multiple bridges may lead to undefined behavior> .
If you’re well-connected in the merchant silicon industry, sign an NDA with Marvell, Broadcom, or Nvidia/Mellanox and see for yourself internally, there’s no way of NOT doing single bridge-only to ensure 100% clean hardware offloading without incurring computational costs or financial costs of manufacturing such ASICs.
I contacted support about this issue and they responded that they will consider improving the behavior for VPLS when they are added to the bridge and VLANs are used.
