Skip to content

mDNS Repeater

Multicast DNS (mDNS) enables zero-configuration service discovery on local networks. Devices broadcast service announcements to the link-local multicast address 224.0.0.251 on UDP port 5353, allowing clients to discover printers, speakers, smart home devices, and other services without a central DNS server.

Because mDNS uses link-local multicast, it does not cross L3 subnet boundaries by default. When your network uses VLANs or separate subnets — such as isolating IoT devices from your main LAN — mDNS discovery fails between segments. RouterOS includes a built-in mDNS repeater that forwards mDNS packets between designated interfaces, restoring cross-subnet discovery without collapsing your network segmentation.

Common use cases:

  • AirPlay and AirPrint across VLAN boundaries
  • Google Chromecast/Cast discovery from a separate VLAN
  • Apple Bonjour and HomeKit device visibility
  • Home automation platforms (Home Assistant, etc.) discovering IoT devices
  • Network-attached storage (NAS) discovery

Note: The mDNS repeater only handles IPv4 mDNS traffic. IPv6 mDNS (link-local multicast to ff02::fb) is not supported. VRF instances are also not supported.

  • RouterOS 7.x with /ip mdns menu available
  • Interfaces for each VLAN or subnet participating in discovery must be present as L3 interfaces on the router (e.g., VLAN interfaces with IP addresses)
  • Bridge VLAN filtering: if using VLAN-filtered bridges, be aware that mDNS multicast is not forwarded across VLAN boundaries at the bridge level — the repeater operates at L3 and requires routed VLAN interfaces

The repeater is disabled by default. Enable it with:

/ip mdns set disabled=no

Only one mDNS repeater instance exists per device. There is no need to create multiple instances.

Add each interface that should participate in mDNS forwarding. The repeater forwards mDNS packets received on any listed interface to all other listed interfaces.

/ip mdns interface add interface=vlan10
/ip mdns interface add interface=vlan20

Example: Home LAN and IoT VLAN

/ip mdns set disabled=no
/ip mdns interface add interface=bridge-lan
/ip mdns interface add interface=vlan-iot

Example: Three-VLAN setup (main, IoT, media)

/ip mdns set disabled=no
/ip mdns interface add interface=vlan10-main
/ip mdns interface add interface=vlan20-iot
/ip mdns interface add interface=vlan30-media
ParameterTypeDefaultDescription
interfacestringName of the interface to include in mDNS forwarding
disabledyes | nonoExclude this interface from forwarding while keeping the entry
/ip mdns interface remove [find interface=vlan20-iot]

To temporarily exclude an interface without removing it:

/ip mdns interface set [find interface=vlan20-iot] disabled=yes

If your firewall has a default-drop policy, you must permit mDNS traffic. Add rules before your drop rules:

# Allow mDNS queries to the router itself (input chain)
/ip firewall filter
add chain=input action=accept protocol=udp dst-address=224.0.0.251 dst-port=5353 \
comment="mDNS: allow repeater input"
# Allow mDNS forwarding between VLANs
/ip firewall filter
add chain=forward action=accept protocol=udp dst-address=224.0.0.251 dst-port=5353 \
comment="mDNS: allow cross-VLAN forwarding"
/ip mdns print

Expected output when enabled:

disabled: no
cache-entries: 24
/ip mdns interface print
Flags: X - disabled
# INTERFACE
0 vlan10-main
1 vlan20-iot
2 vlan30-media

The repeater maintains a cache of discovered service records:

/ip mdns cache print

This shows services that have been announced and cached, such as _airplay._tcp, _googlecast._tcp, and _printer._tcp entries.

To clear all cached mDNS records:

/ip mdns cache flush

To confirm mDNS traffic is flowing on an interface:

/tool sniffer quick interface=vlan20-iot ip-protocol=udp port=5353

You should see multicast packets destined to 224.0.0.251 when devices are announcing services.

Discovery still fails after enabling the repeater

Section titled “Discovery still fails after enabling the repeater”
  1. Verify interfaces are routed, not bridged at L2 — the repeater works at L3. If your VLANs are bridged together with VLAN filtering enabled, mDNS multicast is not forwarded across VLAN IDs at the bridge level. Each VLAN must have its own L3 interface (IP address) on the router.

  2. Confirm both interfaces are listed — run /ip mdns interface print and verify both the source and destination VLANs appear and are not disabled.

  3. Check firewall rules — run /ip firewall filter print and look for rules that may drop UDP port 5353 or the 224.0.0.251 destination before the traffic reaches the repeater.

When VLAN filtering is enabled on a RouterOS bridge, link-local multicast (including mDNS) is not forwarded between VLAN-tagged ports at the bridge layer. The repeater cannot compensate for this at L2.

Solution: Use routed VLAN interfaces. Create a VLAN interface per VLAN and assign an IP address:

/interface vlan add name=vlan10 vlan-id=10 interface=bridge
/interface vlan add name=vlan20 vlan-id=20 interface=bridge
/ip address add address=10.10.10.1/24 interface=vlan10
/ip address add address=10.20.20.1/24 interface=vlan20
/ip mdns interface add interface=vlan10
/ip mdns interface add interface=vlan20

IGMP snooping on a bridge can suppress link-local multicast forwarding to ports that have not explicitly joined the multicast group. mDNS devices do not send IGMP join messages, so the bridge may stop flooding mDNS frames to some ports.

Diagnosis: Temporarily disable IGMP snooping to test:

/interface bridge set [find name=bridge] igmp-snooping=no

If discovery recovers, re-enable snooping and add a static multicast entry to ensure mDNS frames are always flooded:

/interface bridge mdb add group=224.0.0.251 bridge=bridge ports=ether1,ether2,vlan10,vlan20

Warning: Enabling IGMP snooping disables hardware offloading on many lower-end devices (RB951, hAP series, etc.). Test performance impact before deploying in production.

mDNS packets are forwarded but service still does not work

Section titled “mDNS packets are forwarded but service still does not work”

Some services require more than mDNS discovery — they also need unicast traffic to flow between subnets for pairing, control channels, or authentication. Ensure your firewall permits:

  • TCP/UDP traffic from the client VLAN to the device’s service port
  • Return traffic (or use connection-state=established,related rules)

For example, AirPlay requires TCP 7000 and TCP 49152+ in addition to mDNS discovery.

If mDNS repeater processing causes elevated CPU usage, this is typically due to a large number of mDNS devices broadcasting frequently. Limit the interfaces to only those that need cross-VLAN discovery — do not add all interfaces if only a subset requires it.