I have a network set up something like the following:
Device A <---> Router A <---> Router B <---> Device B
where Router A is a tp-link Archer AX73, and Router B is a tp-link Archer C7. Router B is flashed with OpenWRT, and Router A is using stock firmware. Router B is set up to be a wireless bridge between Router A’s network, and its own (it was set up using this guide).
What I am wondering is if Device A can find, say, Device B.local, using Avahi (assuming Device A, and Device B both have Avahi installed, and running), over this bridged network. So far, I haven’t been able to get it to work, so I’m wondering if it is possible at all. I have read that Avahi only works on a local network, but I was wondering if it could be bridged.
UPDATE (2024-01-16T01:28Z):
The issues that I mentioned in this post have since been solved. The majority of the issues stemmed from the fact that the relay software that I was using, relayd, doesn’t support ipv6. All the tests that I was conducting were defaulting to ipv6, so it was appearing like the bridge was failing unpredictably. Since that realization was made, and countermeasures were enacted, the problem was solved.
Avahi uses mDNS which is a multicast protocol. Multicast is designed to be link-local only: it ends at the edge of a broadcast domain. Router A would also need to bridge in order for that to work (i.e. Device A and B would need to have the same broadcast ip).
On the other hand, there are ways of setting up Multicast Forwarding if the router supports it, or you could have a device in both networks that does Avahi/mDNS Reflection.
https://www.cisco.com/assets/sol/sb/Switches_Emulators_v2_3_5_xx/help/250/index.html#page/tesla_250_olh/multi_forwarding.html https://serverfault.com/questions/121032/forward-mdns-from-one-subnet-to-another
Router A would also need to bridge in order for that to work
Why would Router A also need to be a bridge? Router B is configured to bridge its devices to Router A’s network, so, from what I understand, its devices are treated as if they are on Router A’s network – bridging is layer 2, and mDNS is layer 3 (afaik), so Avahi should be able to resolve across the bridge.
On the other hand, there are ways of setting up Multicast Forwarding if the router supports it, or you could have a device in both networks that does Avahi/mDNS Reflection.
Wouldn’t this only matter if Device A, and Device B were on two separate vlan’s?
These are routed networks, and you need avahi reflector set up to mirror between A and PtP and between B and PtP
Router B is bridging Device B to Router A’s network, so they aren’t on separate vlans; thus, it shouldn’t require an mDNS reflector as that repeats mDNS between separate subnets.
Then I don’t understand your topology. However, I still think you need the reflector on both routers
Afaik, an mDNS reflector is only needed to cross subnets – both subnets and mDNS function on layer 3. Bridging occurs on layer 2, and since mDNS functions in layer 3 (ipv4 multicast is layer 3), the bridge itself is invisible to it.
This works if B has an interface that is connected to the A subnet, but not if you have a PtP between the two routers
This works if B has an interface that is connected to the A subnet
I’m not sure I understand exactly what you mean. Is it not given that if two routers are connected to each other then an interface from either of them will be connected to the other?
but not if you have a PtP between the two routers
What do you mean by PtP? Are you referring to something like WDS, or, in my case, relayd?
No, with PtP I meant a point to point link on a dedicated interface just for the two routers. https://image2.slideserve.com/5192070/point-to-point-sub-interfaces-l.jpg
This sounds more like running double NAT with 2 routed networks? Are your clients all on the same subnet, or does router B have its own subnet?
Make sure you’re actually doing a bridge and not adding a second router, then everything will work including avahi.
Are your clients all on the same subnet
Router A (
192.168.0.1) is a different subnet than router B (192.168.2.1).Make sure you’re actually doing a bridge
Bridge was added using the linked guide (it uses relayd).
The majority of the issues stemmed from the fact that the relay software that I was using, relayd, doesn’t support ipv6. All the tests that I was conducting were defaulting to ipv6, so it was appearing like the bridge was failing unpredictably. Since that realization was made, and countermeasures were enacted, the problem was solved.
I hope this means you changed or fixed the software and not that you disabled IPv6.
👀
