Configuring mDNS Repeater
Overview
mDNS (Multicast DNS) Repeater can help forward mDNS request/reply packets between different subnets/VLANs. With this function, you can create a forwarding rule to allow the devices in the specified Client VLAN to discover the mDNS service in the specified Service VLAN. You can also specify the services to be forwarded.
Configuration
Please follow the configuration steps below to configure the mDNS repeater via the Omada SDN Controller v5.6 or later version.
1. Go to Settings > Services > mDNS
2. Click + Create New Rule to create a new mDNS forwarding rule.
3. Specify the parameters.
Name: Specify the rule name for identification.
Status: Enable or disable this rule.
Device Type: Specify the device type (AP or Gateway) for which the rule takes effect.
- Gateway
*mDNS support is added to Gateway since Omada SDN Controller v5.6, which requires both your Omada Router and Omada Controller upgrading to SDN 5.6.
**The Gateway type doesn't support configuring Bonjour Service until Omada SDN Controller v5.8, which requires to upgrade the Router firmware to adapt 5.8.
- For Omada SDN Controller v5.6 or 5.7:
Network: Specify which network that mDNS request/reply packets can cross, that is, the range of services that can be found across networks/VLANs.
- For Omada SDN Controller v5.8 or later version:
Bonjour Service: Specify the services to be forwarded. (you can also create new Bonjour service types by click Manage Bonjour Service)
Service Network:
Network: Specify the network where the mDNS services are located.
Client Network:
Network: Specify the VLANs where the Client devices are located.
- AP
*mDNS support is added to AP since Omada SDN Controller v5.7, which requires both your Omada EAP and Omada Controller upgrading to SDN 5.7.
Bonjour Service: Specify the services to be forwarded. (you can also create new Bonjour service types by click Manage Bonjour Service)
Service Network:
VLAN: Specify the VLANs where the mDNS services are located. You can enter VLAN ranges or VLAN IDs separated by comma.
Client Network:
VLAN: Specify the VLANs where the Client devices are located. You can enter VLAN ranges or VLAN IDs separated by comma.
Note:
1) mDNS rules in AP type and Gateway type are mutually exclusive.
2) To make mDNS configuration take effect, please ensure both the AP/Gateway and Omada Controller are upgraded to the corresponding adapted firmware.
For example, to make the mDNS configuration in AP type work, ensure both your EAP and Omada Controller are upgraded to adapt to Omada SDN Controller v5.7.
This isn't working correctly for me , as I described in this post: https://community.tp-link.com/en/business/forum/topic/593654https://community.tp-link.com/en/business/forum/topic/593654
"I added " _googlecast._tcp.local" to bonjour services, and then created an mDNS service, with the Chromecast as the VLAN SERVICE NETWORK and my laptop as the VLAN CLIENT NETWORK. But I still could not cast to the chromecast. Please let me know if this is possible? I added " _googlecast._tcp.local" to bonjour services, and then created an mDNS service, with the Chromecast as the VLAN SERVICE NETWORK and my laptop as the VLAN CLIENT NETWORK. But I still could not cast to the chromecast. Please let me know if this is possible? "
It seems that you need to add the bonjour services to get the Chromecast work across VLAN.
So far, only the mDNS in AP type has Bonjour Service that can be configured. To make the mDNS configuration in AP type take effect, we need to ensure both the EAP and Omada SDN Controller are upgraded to SDN 5.7 firmware (the firmware adapted to Omada SDN Controller v5.7). While the SDN 5.7 firmware for the EAP hasn't been released yet, you may need to wait for the EAP firmware updates to make it.
FYI, the mDNS in Gateway type will add the configuration for Bonjour Service in the subsequent firmware upgrades. Stay tuned!
mDNS randomly only works, I have checked all the settings why am I experiencing this? and when it does it's a huge lag in response time. The capacity is very low on my setup, what is causing this to not work when I am running the firmware that should support this? It seems when mDNS does work is only after full power cycles. Please advise is this a bug in development or do you have to flash the rest of all devices to work.
Controller: OC200 1.1 Firmware 1.27.7 Build 20221206 Rel.58608
Gateway: ER605 V.20 Version: 2.1.1 Firmware version: 2.1.1 Build 20230115 Rel.77774
Switch: TL-SG2210P V3.20 Version 3.20.8 Firmware version: : 3.20.8 Build 20221130 Rel.42340
Switch: TL-SG2008 V3.0 Version 3.0.7 Firmware version: 3.0.7 Build 20221130 Rel.42340
AP: EAP235-Wall(US) V1.0 Version 3.1.0 Firmware version: 3.1.0 Build 20210721 Rel. 46004
AP: EAP235-Wall(US) V1.0 Version 3.1.0 Firmware version: 3.1.0 Build 20210721 Rel. 46004
AP: EAP225 (US) V3.0 Version 5.0.9 Firmware version: 5.0.9 Build 20220429 Rel. 43558
Having issues geting AirPrint, GoogleTV/Chromecast, and other services from effectively using mDNS. Hardware appropriate versions wth updated firmware. 5.8 software controller.
I would like to corroborate D-Trig statements. I have a similar setup:
- Controller OC200 2.0, Firmware: 2.9.3 Build 20230328 Rel.52390
- Router ER605 v2.0, Firmware: 2.1.2 Build 20230210 Rel.62992
- Switch TL-SG2008P v3.0, Firmware: 3.0.5 Build 20230602 Rel.73473
- AP EAP660 HD(US) v1.0, Firmware 1.1.1 Build 20220118 Rel. 60852
- AP EAP660 HD(US) v1.0, Firmware 1.1.1 Build 20220118 Rel. 60852
I have a Linux local server which has its own mDNS, accessible without obstacles from the same VLAN. When I add a custom Gateway rule to allow mDNS services from the "Media" VLAN to be observable from other VLANS, it works for a while (rough estimate: 1h) and then suddenly stops resolving the DN. 
Also note an unexpected behavior. If I don't select "All" client networks, the mDNS from Media network won't be resolved from any individual VLAN authorized in the "Client Network" field. Each of these VLANs is an interface. There are 4 (10, 20, 30, 40).
Lastly, I can confirm very high pings, a couple of hundreds ms, when resolving cross-VLAN mDNS domain names, while each device involved in the test has a ping to Gateway < 10ms.
EDIT: more tests. Ping from Macbook to Gateway via AP: 230 packets transmitted, 230 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 3.996/9.975/70.529/4.801 ms Ping from Server to Gateway via AP: 91 packets transmitted, 91 received, 0% packet loss, time 90142ms rtt min/avg/max/mdev = 2.271/5.800/9.199/1.441 ms Ping from Macbook to Server on different VLAN via AP: 138 packets transmitted, 138 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 7.692/161.216/417.810/104.835 ms
Ping from Server to Macbook on same VLAN via AP: 134 packets transmitted, 129 received, 3.73134% packet loss, time 133726ms rtt min/avg/max/mdev = 6.094/270.269/1225.363/393.904 ms, pipe 2
So obviously, there is a big issue with local packet transmission, that is probably unrelated to mDNS.
I'm having issues with the option for the gateway being grayed out.
My config:
OC200 V2 FW:2.9.3
ER8411 v1.0 FW:1.0.3
TL-SG2428P v4.0 FW: 4.0.6
TL-SG3210XHP-M2 v2.0 FW:2.0.6
EAP245(Canada) v3.0[Custom... FW:5.0.5
EAP245(Canada) v3.0[Custom... FW:5.0.5
EAP610(US) v1.0[Custom] FW:1.0.4
I have updated all the firmware's to the latest ones possible in Canada, I only have the option for AP mode and not Gateway mode. It tells me "Up to 0 mDNS rule can be created for the gateway." when I hover over the gateway option.
@Jbohbot I had the same issues. I pulled down the early access version of the controller firmware and that seemed to fix it, at least on the configuration side. I believe it was version 5.12.6, just released a couple of days ago. As others have reported, it does seem to cut out after a bit. Hopefully they will fix this before full release.
That said, the number of services you can forward seems really limited. You can only have 15 total service profiles (10 of which are hard-coded and not editable) and only 3 services per custom group. IMHO, for any scenario involving a significant IoT presency, that is extremely limiting. I'm guessing they coded those limits against the hardware capacity of the ER605. As an owner of an ER8411, it seems pretty lame that we are subject to the lowest common denominator. TP-Linik, please fix this!