Arista Multicast DNS Gateway (EOS-4.26 ++)

Description

A mDNS Gateway extends the link-local scope of mDNS messages to additional subnets
to provide service discovery and domain name resolution over an extended link-local
multicast domain. A mDNS gateway can also peer with additional mDNS gateways to
extend the logical link-local multicast domain to include directly connected subnets on a
mDNS gateway peer. To manage services in the extended link-local multicast domain, a
gateway also specifies service rule policies that can:

filter on interested service types;
control the discoverable subnets for a given client subnet; and,
limit the discoverable services based on the geographical location of the client.

The mDNS gateway respects the link-local scope of mDNS messages and does not
propagate mDNS traffic between subnets when building extended link-local multicast
domain. Each mDNS gateway will snoop mDNS announcements and proxy mDNS queries based on the learned results. When a logical link-local multicast domain stretches
multiple gateways a mDNS query will be forwarded to a mDNS gateway peer to query
mDNS announcements learned on the peer.

Platform compatibility

The feature is platform independent.

Terminologies

Aggregation Switch

A termination VTEP endpoint for multiple APs. An aggregation switch can be the endpoint
of all APs or a subset of the APs in the network.

Gateway

The mDNS agent that replies to mDNS queries with DNS records from its database, and
populates the database with records from mDNS responses.

Link

Represents a single link-local multicast domain, usually synonymous with a subnet (but
not always). It is the same scope a link-local multicast DNS can normally reach.

It is recommended that link identifiers be uniquely mapped to multicast link-local
segments. That is, if a VXLAN segment (VNI) spans over multiple VTEPs running
Gateway agents, they should be configured with the same link identifier. Having multiple
link identifiers mapping to a single link-local segment can potentially introduce duplicated
multicast traffic.

Local Link

A Link directly connected to a Gateway.

Remote Link

A Local Link directly connected to a remote Gateway.

Unique Records

Records that are normally announced by only one host or services, for example, A,
AAAA, SRV, or TXT mDNS records.

Shared Records

Records that may have more than one responder, for example, PTR mDNS records (e.g.,
_printer._tcp.local.).

Service Type

The service domain name excluding the service instance name ( the first DNS label ). For
example, the service type of “printer._ipp._tcp.local.” is “_ipp._tcp.local.” .

DNS Stateful Operation (DSO)

The protocol that is used to communicate between gateways.

Configuration

The mDNS gateway agent is enabled with

`switch(config)#mdns`
`switch(config-mdns)#no disabled`
`switch(config-mdns)#show active`
`mdns`
`no disabled`

At this point the mDNS gateway agent is running but needs further configuration to

define the L3 interfaces that should join the mDNS multicast group; and
define the service policies that indicate the service types of interest, the extended
link-local multicast domains, and the geographical locations of interest.

L3 Interfaces

A routed or VLAN interface can join a mDNS multicast group.

switch(config-if-Et1)#mdns ipv4 ?
default-tag Specify a default tag for DNS records received
link Specify link ID to be advertised to remote gateways
<cr>
switch(config-if-Et1)#mdns ipv4
switch(config-if-Et1)#show mdns links
Interface Address Family Link ID Status
Ethernet1 ipv4 active

A L3 interface that is configured to join a mDNS multicast group can only be referenced
by local service policy definitions. When creating an extended link-local multicast domain
that spans the local gateway, the L3 interface must be provided with a global unique link
identifier so that it can be referenced by other gateways.

A routed or VLAN interface that has joined the mDNS multicast group can specify a link
identifier.

switch(config-if-Et1)#mdns ipv4 link ?
WORD Link ID of this interface
switch(config-if-Et1)#mdns ipv4 link switch-et1
switch(config-if-Et1)#show mdns links
Interface Address Family Link ID Status
Ethernet1 ipv4 switch-et1 active

To support geographical filtering, services are associated with location tags. A service
record can be tagged with a location through the use of a CloudVision-Wifi UI to configure
a location tag on Arista APs that support location tagging or by configuring a defaulttag
on the L3 interface that has joined the mDNS multicast group. The default-tag is
only applied to service records that are not already tagged with a location.

switch(config-if-Et1)#mdns ipv4 default-tag ?
WORD Default tag name
switch(config-if-Et1)#mdns ipv4 default-tag floor1-buildingA

Service Policies

A service policy defines

the interested mDNS service types
the set of Local Links where mDNS queries are accepted
the set of Local and Remote Links where service records can be learned
the policy used to filter service records by their location tag

Multiple service policies can be defined and services can have shared properties.

A service policy is configured with

switch(config-mdns)#service ?
WORD Name of service group
switch(config-mdns)#service printers
switch(config-mdns-service-printer)#

A set of service types can be provided to allow all service types.

switch(config-mdns-service-printer)#type ?
WORD List of service types allowed by the service rule
add Add to list
remove Remove from list
switch(config-mdns)#type _ipp._tcp. _ipps._tcp. _eapsp._tcp.

A set of query links can be specified to indicate the Local Links that accept mDNS
queries.

switch(config-mdns-service-printer)#query ?
Ethernet hardware Ethernet interface
Vlan Logical interface into a VLAN
add Add to list
remove Remove from list
switch(config-mdns-service-printer)#query Vlan10, Vlan20

A set of response links can be specified to indicate the Links from which service records are learned. The set of Links can include Local and Remote Links.

switch(config-mdns-service-printer)#response ?
interface Specify local interface(s)
link Specify names of these links
switch(config-mdns-service-printer)#response interface ?
Ethernet hardware Ethernet interface
Vlan Logical interface into a VLAN
add Add to list
remove Remove from list
switch(config-mdns-service-printer)#response interface Vlan 30
switch(config-mdns-service-printer)#response link ?
WORD Link name
add Add to list
remove Remove from list
switch(config-mdns-service-printer)#response link peer-gateway-Vlan30

When service records are tagged with a location, we can limit the service records to be returned to a query link. Service records can be limited to those matching the tag of the mDNS query with by-tag .

switch(config-mdns-service-foo)#match ?
by-tag Limit query results to records whose location tag matches the query's
location
group Limit query results to records whose location tag matches the specified
filter(s)

Service records can be limited to those matching a set of filters.

switch(config-mdns-service-foo)#match group ?
WORD List of filters
add Add to list
remove Remove from list
switch(config-mdns-service-foo)#match group floor1 floor2

Gateway Peering

When building extended link-local multicast domains that include subnets from remote mDNS gateways, the mDNS gateways must peer with each other over a bi-directional TCP connection.

Given a topology where gateway switch1 peers with switch2 , both gateways start listening for DSO PDU over a TCP connection as follows.

switch1(config-mdns)#dso ?
server Configure DSO server to listen on a TCP port
switch1(config-mdns)#dso server ?
ipv4 Listen on an IPv4 address
switch1(config-mdns)#dso server ipv4 ?
tcp-port Configure TCP port that DSO server uses
<cr>
switch1(config-mdns)#dso server ipv4 tcp-port ?
<1-65535> Configure TCP port to this value
switch1(config-mdns)#dso server ipv4 tcp-port 8853

Port 8853 is the default port number for DSO. The following will have the same effect as above:

switch1(config-mdns)#dso server ipv4

The gateway switch1 peers with switch2 as follows.

switch1(config-mdns)#remote-gateway ?
ipv4 Specify IPv4 remote gateway
switch1(config-mdns)#remote-gateway ipv4 ?
A.B.C.D Remote gateway IP address
switch1(config-mdns)#remote-gateway ipv4 100.0.0.2

A gateway can peer with multiple remote mDNS gateways.

switch1(config-mdns)#remote-gateway ipv4 100.0.0.3

Control Plane Policing

Gateways can be hit with a large number of queries which can lead to CPU starvation and affect other network critical processes. To avoid this, we can utilize Control Plane Policing (COPP) to rate limit mDNS traffic. For example, we can configure as follows to rate limit mDNS traffic to 100 pps for a switch that supports dynamic class maps:

!
ip access-list copp-acl-mdns
10 permit udp any host 224.0.0.251
!
class-map type copp match-any copp-class-mdns
match ip access-group copp-acl-mdns
!
policy-map type copp copp-system-policy
class copp-class-mdns
shape pps 100
bandwidth pps 100
!

Note that the above access list indicates that incoming UDP packets to destination 224.0.0.251 will be policed (224.0.0.251 is the multicast IP address used for the mDns protocol).

Sample Topologies

Single Gateway

A sample configuration of the gateway above would be:

.........
!
vlan 2-4
!
interface Ethernet1
switchport access vlan 2
!
interface Ethernet2
switchport access vlan 3
!
interface Ethernet3
!
interface Ethernet4
switchport access vlan 4
!
interface Management1
!
interface Vlan2
ip address 2.0.0.1/24
mdns ipv4
!
interface Vlan3
ip address 3.0.0.1/24
mdns ipv4
!
Interface Vlan4
ip address 4.0.0.1/24
mdns ipv4
!
ip routing
!
system control-plane
service-policy input copp-system-policy
!
mdns
no disabled
!
service nlrtr2
type _ftp._tcp. _ipp._tcp.
query Vlan4
response link Vlan2, Vlan3
!
end

Note that the service rule specifies that the query link is VLAN 4 where the client is connected to and the response links are VLAN 2 and VLAN 3 where the printer and ftp services are connected to. Also, the service rule specifies that the service types that the gateway is interested in are ftp and printer services. With this service rule, the client is able to discover both the printer and ftp services.

Multiple Gateways

A sample configuration of Gateway1 above would be:

.........
!
vlan 3-4
!
interface Ethernet1
switchport access vlan 3
!
interface Ethernet2
switchport access vlan 4
!
interface Ethernet3
!
interface Ethernet4
!
interface Ethernet5
no switchport
ip address 1.0.0.49/29
!
interface Management1
!
interface Vlan3
ip address 3.0.0.1/24
mdns ipv4 link Vlan3-link
!
interface Vlan4
ip address 4.0.0.1/24
mdns ipv4 link Vlan4-link
!
ip routing
!
system control-plane
service-policy input copp-system-policy
!
mdns
no disabled
remote-gateway ipv4 1.0.0.41
dso server ipv4
!
service foo
type _ftp._tcp.
response link Vlan3-link Vlan4-link Vlan5-link
!
ip route 0.0.0.0/0 1.0.0.51
!
end

Above, the DSO server is configured and Gateway2 is configured as a remote gateway by specifying Gateway2’s IP address 1.0.0.41.

Note that link identifiers are used to specify the response links within the service rule.
This is to include links on the remote gateway as a response link ( Vlan5-link is a link on the remote gateway). Also, note that the query link is not specified within the service rule; there is no need to specify a query link as there are no local clients of Gateway1.

Similar to Gateway1, the sample configuration for Gateway2 would be:

.........
!
vlan 5-6
!
interface Ethernet1
switchport access vlan 5
!
interface Ethernet2
switchport access vlan 6
!
interface Ethernet3
!
interface Ethernet4
!
interface Ethernet5
no switchport
ip address 1.0.0.41/29
!
interface Management1
!
interface Vlan5
ip address 5.0.0.1/24
mdns ipv4 link Vlan5-link
!
interface Vlan6
ip address 6.0.0.1/24
mdns ipv4 link Vlan6-link
!
ip routing
!
system control-plane
service-policy input copp-system-policy
!
mdns
no disabled
remote-gateway ipv4 1.0.0.49
dso server ipv4
!
service foo
type _ftp._tcp.
query Vlan6
response link Vlan3-link Vlan4-link Vlan5-link
!
ip route 0.0.0.0/0 1.0.0.43
!
end

Similar to Gateway1, DSO server is configured on Gateway2 and Gateway1 is configured to be a remote gateway on Gateway2 by specifying Gateway1’s IP address 1.0.0.49.
Also, link identifiers are used to accommodate remote links as response links within the service rule ( Vlan3-link Vlan4-link are remote links).

Different from Gateway1, a query link Vlan6 is specified on the service rule of
Gateway2. This allows incoming queries from the local client through VLAN 6 to get processed by Gateway2; local client queries coming from other VLANs will be ignored.

Configuring with VXLAN

In the above topology, we assume that VXLAN is established across the two gateways.
A sample configuration of Gateway1 above would be:

!
vlan 10-11
!
interface Ethernet1
switchport access vlan 10
!
interface Ethernet2
Switchport access vlan 11
!
interface Ethernet3
!
interface Ethernet4
!
interface Ethernet5
no switchport
ip address 1.0.0.33/29
!
interface Loopback0
ip address 10.10.10.101/32
!
interface Management1
!
interface Vlan10
ip address 10.0.0.1/24
mdns ipv4 link Link-Vlan10
!
interface Vlan11
ip address 11.0.0.1/24
mdns ipv4 link Link-Vlan11
!
interface Vxlan1
vxlan source-interface Loopback0
vxlan udp-port 4789
vxlan vlan 10 vni 1010
vxlan vlan 11 vni 1011
vxlan vlan 10 flood vtep 10.10.10.102
vxlan vlan 11 flood vtep 10.10.10.102
!
ip routing
!
system control-plane
service-policy input copp-system-policy
!
mdns
no disabled
remote-gateway ipv4 1.0.0.1
dso server ipv4
!
service ftp_services
type _ftp._tcp.
query Vlan10
response link Link-Vlan11
!
ip route 0.0.0.0/0 1.0.0.35
!
end

And, a sample configuration of Gateway2 above would be:

!
vlan 10-11
!
interface Ethernet1
switchport access vlan 10
!
interface Ethernet2
switchport access vlan 11
!
interface Ethernet3
!
interface Ethernet4
!
interface Ethernet5
no switchport
ip address 1.0.0.1/29
!
interface Loopback0
ip address 10.10.10.102/32
!
interface Management1
!
interface Vlan10
ip address 10.0.0.1/24
mdns ipv4 link Link-Vlan10
!
interface Vlan11
ip address 11.0.0.1/24
mdns ipv4 link Link-Vlan11
!
interface Vxlan1
vxlan source-interface Loopback0
vxlan udp-port 4789
vxlan vlan 10 vni 1010
vxlan vlan 11 vni 1011
vxlan vlan 10 flood vtep 10.10.10.101
vxlan vlan 11 flood vtep 10.10.10.101
!
ip routing
!
system control-plane
service-policy input copp-system-policy
!
mdns
no disabled
remote-gateway ipv4 1.0.0.33
dso server ipv4
!
service ftp_services
type _ftp._tcp.
query Vlan10
response link Link-Vlan11
!
ip route 0.0.0.0/0 1.0.0.3
!
end

Notice that both Gateway1 and Gateway2 have identical service rules (the query link being Vlan 10 and the response link being Vlan 11) with DSO connections between them. In this case, both FTP1 and FTP2 are learned by both Gateway1 and Gateway2.
In addition, a client will receive multiple responses for its query (as a local response, as a response via VXLAN, and as a response via DSO connection).

To reduce duplicate responses, we can consider to configure as follows:
For Gateway1:

mdns
no disabled
remote-gateway ipv4 1.0.0.1
dso server ipv4
!
service ftp_services
type _ftp._tcp.
query Vlan10

And, for Gateway2:

mdns
no disabled
remote-gateway ipv4 1.0.0.33
dso server ipv4
!
service ftp_services
type _ftp._tcp.
response link Link-Vlan11

Notice that VLAN 10 serves as a query link on Gateway1 but not on Gateway2. Also, notice that VLAN 11 serves as a response link on Gateway2 but not on Gateway1. In this way, services will only get learned at Gateway2; FTP2 gets learned locally and FTP1 gets learned through VXLAN. Also, client queries will only be valid on Gateway1; queries from Client1 will be accepted through its local link and queries from Client2 will be accepted through VXLAN.

The following are query-response paths for Client1 and Client2:

Client1 sends a query to Gateway1. Gateway1 accepts the query. The query gets forwarded to Gateway2 via DSO connection. Gateway2 sends response back to Gateway1 over DSO connection. Gateway1 forwards response to Client1.
Client2 sends a query to Gateway2. Gateway2 forwards the query to Gateway1 via VXLAN. Gateway1 accepts the query. The query gets forwarded to Gateway2 via DSO connection. Gateway2 sends response back to Gateway1 over DSO connection. Gateway1 forwards response to Gateway2 via VXLAN. Gateway2 forwards response to Client2.

Integration with Arista Access Points

In the above topology, we assume that AP1 and AP2 tunnel traffic to Gateway1 and Gateway2, respectively. Also, we establish VXLAN to span across the two gateways.

A sample configuration of Gateway1 would be the same as the one in section
“Configuring with VXLAN” except having

interface Vxlan1
vxlan source-interface Loopback0
vxlan udp-port 4789
vxlan bridging vtep-to-vtep
vxlan flood vtep learned data-plane
vxlan vlan 10 vni 1010
vxlan vlan 11 vni 1011
vxlan vlan 10 flood vtep 10.10.10.102
vxlan vlan 11 flood vtep 10.10.10.102

and adding

ip route 10.10.10.3/32 1.0.0.51

where 10.10.10.3/32 corresponds to the VTEP IP of AP1 and 1.0.0.51 is the interface IP of AP1 that is connected to Gateway1.

A sample configuration of Gateway2 would be the same as the one in section
“Configuring with VXLAN” except having

interface Vxlan1
vxlan source-interface Loopback0
vxlan udp-port 4789
vxlan bridging vtep-to-vtep
vxlan flood vtep learned data-plane
vxlan vlan 10 vni 1010
vxlan vlan 11 vni 1011
vxlan vlan 10 flood vtep 10.10.10.101
vxlan vlan 11 flood vtep 10.10.10.101

and adding

ip route 10.10.10.4/32 1.0.0.43

where 10.10.10.4/32 corresponds to the VTEP IP of AP2 and 1.0.0.43 is the interface IP of AP2 that is connected to Gateway2.
Note that the flooding behavior is set up as follows:

APs flood traffic to their corresponding local gateway (APs tunnel traffic to
gateways)
vxlan bridging vtep-to-vtep allows flood traffic that came from remote gateway to be locally bridged
vxlan flood vtep learned data-plane adds local AP to the gateway’s flood set
vxlan vlan <vlan> flood vtep <vteps> adds remote gateway to its flood set

Configuring with Mlags

In the above topology, we consider the Mlag peer link to be a connection between trunk ports so the traffic from VLANs 10 and 20 gets forwarded across the peer link.

And, a sample configuration of Primary would be (the configuration of Secondary will be similar):

.........
!
spanning-tree mode mstp
no spanning-tree vlan-id 4094
!
no aaa root
!
vlan 10,20
!
vlan 4094
trunk group peerlink
!
interface Port-Channel20
switchport trunk allowed vlan 10,20
switchport mode trunk
mlag 20
!
interface Ethernet1
channel-group 20 mode on
!
interface Ethernet2
!
interface Ethernet3
switchport mode trunk
switchport trunk group peerlink
!
interface Ethernet4
!
interface Ethernet5
!
interface Ethernet6
!
interface Ethernet7
!
interface Ethernet8
!
interface Ethernet9
!
interface Ethernet10
!
interface Management1
!
interface Vlan10
ip address 100.0.0.1/24
mdns ipv4
!
interface Vlan20
ip address 200.0.0.3/24
mdns ipv4
!
interface Vlan4094
no autostate
ip address 10.0.0.1/24
!
no ip routing
!
system control-plane
service-policy input copp-system-policy
!

mdns
no disabled
!
service primary
type _ftp._tcp. _ipp._tcp.
query Vlan10
response interface Vlan20
!
mlag configuration
domain-id test_domain_1
heartbeat-interval 10000
local-interface Vlan4094
peer-address 10.0.0.2
primary-priority 11
peer-link Ethernet3
reload-delay 0
!
end

Note that the response interface set within the service rule includes VLAN 20. So, both the Primary and the Secondary will learn both FTP and Printer services (service announcement is either learned through the port channel or the peer link). Also, when the client queries for a service, the client might receive duplicate responses (the query arrives on both peers and gets processed which results in multiple responses).

Show commands

The show mdns status displays mDNS status and DSO connection status.

switch#show mdns status
mDNS is running | enabled | disabled
DSO server is running | enabled | disabled
Gateway DSO connections
Address Port Status
1.0.0.3 8853 idle
2.0.0.1 8853 connected
10.0.0.2 8853 timedout
DSO client connections
Address Port
2.0.0.1 23456
10.0.0.2 12345

The show mdns links shows the status of links that listen to mDNS packets.

switch#show mdns links
Interface Address Family Link ID Status
Ethernet4 ipv4 wired-link-1D active
Ethernet5 ipv4 wireless-link-1 inactive

The show mdns service rule displays received service records.
This command displays received service records filtered by ser vice rule
employee_services.

switch#show mdns service rule employee_services
Service Name Interface/Link
Location

-------------------------------------------------------- --------------------- ---

-----

printer1._ipp._tcp.local. Ethernet4/link1
floor1
printer2._ipp._tcp.local. link2
floor7
printer3._universal._subtype._ipp._tcp.local. Ethernet10
floor10
appletv._airplay._tcp.local. Ethernet6
floor3
printer10._ftp._tcp.local. Ethernet2

This command displays received service records filtered by service rule
employee_services and service type _ipp._tcp.

switch#show mdns service rule employee_services type _ipp._tcp.
Service Name Interface/Link
Location

-------------------------------------------------------- --------------------- ---

-----

printer1._ipp._tcp.local. Ethernet4/link1
floor1
printer2._ipp._tcp.local. link2
floor7
printer3._ipp._tcp.local. Ethernet10
floor10

The show mdns service name displays information about service records.
This command displays information about service printer1._ipp._tcp.local. To get service names, show mdns service rule can be run first.

switch#show mdns service name printer1._ipp._tcp.local.
Service Name: printer1._ipp._tcp.local.
Interface: Ethernet1
Host: printer1.local., printer1(1).local.
Interface: Ethernet4
Link: link4
Host: printer1(2).local.
Interface: Ethernet10
Link: link10
Interface: --
Link: remote-link
Host: printer1(3).local.

This command displays detailed information about service printer1._ipp._tcp.local.

switch#show mdns service name printer1._ipp._tcp.local. detail
Service Name: printer1._ipp._tcp.local.
TXT record: 15 77 97 99 66 111 111 107 80 114 111 49 50 44 49 15 77 97
99 66 111 111 107 80 114 111 49 50 44 49 15 77 97 99 66 111
111 107 80 114 111 49 50 44 49
TXT record: 15 77 97 99 66 111 111 107 80 114 111 49 50 44 49 15 77 97
99 66 111 111 107 80 114 111 49 50 44 49 15 77 97 99 66 111
111 107 80 114 111 49 50 44 49 15 77 97 99 66 ...(75 bytes)
Interface: Ethernet4
Link: link4
Host: printer1.local.
Location:
Priority: 22
Weight: 17
Port: 8080
V4 Address: 10.0.0.1, 10.0.0.2
V6 Address: fe80::1234, fe80::5678
TXT record: 5 109 111 100 101 108
TXT record: 15 77 97 99 66 111 111 107 80 114 111 49 50 44 49 15 77
99 66 111 111 107 80 114 111 49 50 44 49 15 77 97 99 66
111 107 80 114 111 49 50 44 49
Record (Type 21): 15 77 97 99 66 111 111 107 80 114 111 49 50 44 49
Record (Type 21): 15 77 97 99 66 111 111 107 80 114 111 49 50 44 49
99 66 111 111 107 80 114 111 49 50 44 49 15 77 97
111 107 80 114 111 49 50 44 49
Record (Type 26): 5 109 111 100 101 108
Host: printer1(1).local.
Priority: 0
Weight: 0
Port: 80
V6 Address: fe80::9abc

The show mdns service type displays available service types from interfaces it received from.

switch#show mdns service type
Interface Address Family Service Type Elapsed Time
Ethernet1 ipv4 _ftp._tcp. 82 days, 19:21:18 ago
Ethernet1 ipv4 _ipp._tcp. 82 days, 19:39:49 ago
Ethernet2 ipv4 _ftp._tcp. 82 days, 19:23:21 ago
Ethernet2 ipv4 _ipp._tcp. 82 days, 19:41:52 ago

This command displays available service types from interface Ethernet1.

switch#show mdns service type interface ethernet 1
Interface Address Family Service Type Elapsed Time
Ethernet1 ipv4 _ftp._tcp. 82 days, 19:21:18 ago
Ethernet1 ipv4 _ipp._tcp. 82 days, 19:39:49 ago

Syslog messages

No relevant syslog messages.

Troubleshooting

The show commands mentioned in the “Show Commands” section can be used for troubleshooting. For example:

show mdns status can be used to check whether McastDns agent is running and whether there are any DSO connections maintained with remote gateways.
show mdns service rule can be used to see if specific services are learned for a given service rule.
show mdns service <service-name> detail can be used to see the content of the service and which interface the service was learned.
show mdns links can be used to check whether a certain interface is serving as a mDNS link.

Tracing

Disclaimer: In some cases, enabling tracing can seriously impact the performance of the switch. Please use it cautiously and seek advice from an Arista representative before enabling this in any production environments.

The following tracing levels may be helpful in understanding unexpected behavior:

trace McastDns setting McastDns*/*

Limitations

A gateway only stores local records in its database. Remote records that are received through the DSO connection will not get stored in the database.
Up to 5000 local service records can be stored in the database of a gateway.
show mdns service commands only display information regarding local services.
Probing (see section 8.1 of RFC6762: Multicast DNS) is not supported. Gateway will not respond to any probing query which limits cross subnet conflict resolution.

Resources

RFC6762: Multicast DNS
Overview of mDNS
RFC8490: DNS Stateful Operations
Overview of types of state exchange between DNS aware devices
DRAFT: dnssd-mdns-relay-00
Introduces the notion of joining mDNS subnets and a way to reach these
subnets over DSO.