Cisco Logo


Architect & DE Discussions

Introduction

With the introduction of Cisco mDNS Service Discovery Gateway in IOS, customers that have implemented the solution are observing client behavior they haven’t seen prior to extending services across subnet boundaries. One of the effects is the duplicate name issue seen when devices with enabled services are moved from one L3 subnet to another L3 subnet and these two subnets happen to be connected to the same router/switch running the Service Discovery Gateway (SDG).

Background

When devices (like a Mac OS X computer) offer a service such as Remote Login (SSH) or Screen Sharing (VNC), they will announce these services using mDNS/Bonjour/Zeroconf using their hostname as configured in ‘System Preferences -> Sharing -> Computer Name’ (see Fig. 1).

preferences

Before a device announces anything, it will first query for its own name (in this case ‘Lab-Mac.local.’) to see if that name has already been taken.

When the device is initially connected to a network running the Service Discovery Feature on a L3 router/switch, that network element will learn that name and everything is OK, it caches it. Those service records typically have a TTL (Time to Live) of over an hour by default (4,500 seconds). Now, if that device will be moved to another L3 segment (either wired or wireless, if the wireless is bridged into a wired segment) it will again query for its name. This time, the L3 router/switch running the cache will already have that service name from the previous connection and it will happily provide an answer. At this point, the device will display a message like the one shown below (Fig. 2) and it will automatically choose a new name.

notification

Solution

The SDG can apply a filter policy either globally or on a per-interface basis. This blog post proposes different service-lists (filters) for L3 segments with only clients, mixed clients and servers or servers only.

Server segments would be considered segments which only have (e.g.) printers or Apple TVs. But even for server segments it makes sense to restrict the learning to specific services and not arbitrarily allow everything. This also helps to keep CPU and memory resource usage low. That said, permitting any service into the cache could be helpful in the beginning to learn what services are out there and what specific service strings they announce to build a more restrictive policy as a result.

The filter list should do the following on incoming mDNS requests:

A real example looks like this:

service-list mdns-sd clients permit 10
 match message-type query
service-list mdns-sd clients permit 20
 match message-type announcement
 match service-type _ipps._tcp
service-list mdns-sd clients permit 30
 match message-type announcement
 match service-type _ipp._tcp
service-list mdns-sd clients permit 40
 match message-type announcement
 match service-type _airplay._tcp
service-list mdns-sd clients permit 50
 match message-type announcement
 match service-type _universal._sub._ipp._tcp
service-list mdns-sd clients deny 60
!
!
service-list mdns-sd permit-all permit 10
!
!
service-list mdns-sd deny-all permit 10
 match message-type query
service-list mdns-sd deny-all deny 20
!
!
service-list mdns-sd aq query
 service-type _ipp._tcp
 service-type _ipps._tcp
 service-type _airplay._tcp
 service-type _universal._sub._ipp._tcp.local
!
service-routing mdns-sd
 service-policy-query aq 3600
!

This then needs to be applied to the appropriate L3 interface like this:

interface Vlan130
 description *** clients live here, but also servers like printers and AppleTVs ***
 ip address dhcp
 service-routing mdns-sd
  service-policy clients IN
  service-policy permit-all OUT
 ipv6 enable
!
interface Vlan140
 description *** no clients, static servers live here (AppleTVs, Printers) ***
 ip address dhcp
 service-routing mdns-sd
  service-policy permit-all IN
  service-policy permit-all OUT
 ipv6 enable
!
interface Vlan150
 description *** only clients, no services at all to be extended ***
 ip address dhcp
 service-routing mdns-sd
  service-policy deny-all IN
  service-policy permit-all OUT
 ipv6 enable
!

The query service-list named ‘aq’ keeps services fresh in the cache by actively querying them every hour (in the given example). One can adapt that timer if needed. Again the query list should contain the services we care about and it should be symmetrical to the filter list of services we want to allow into the cache.

If there’s a pure client VLAN (none of the client services need to be extended), the deny-all service list could be used. It allows queries from the clients but will deny any service announcements.

Note: This list needs to include those services that have to be extended across multiple L3 segments, each as a separate statement. If there are printers attached to client PCs or network attached printers or Apple TVs in a client segment which are only locally used, the ‘deny-all’ list should be used.

Note: There is absolutely nothing we can do when the SDG learns a device name on multiple segments, either at the same time or in a connect/disconnect/connect sequence. Technically, Apple’s implementation could withdraw services when switching SSIDs; actually it doesn’t. And nothing could be done at all if someone unplugs the cable from a port in, say, VLAN 100 and reconnects the same cable into VLAN 200.

Summary

The flexibility of the mDNS filter lists in combination with regular expressions allows to specify exactly which services need to be extended across L3 segments on a router/switch implementing the Service Discovery Gateway. This way, clients can still announce and see services locally but only those services which are required to be seen across subnets are actually extended.

Appendix

 

 

In an effort to keep conversations fresh, Cisco Blogs closes comments after 90 days. Please visit the Cisco Blogs hub page for the latest content.

4 Comments.


  1. Where can I get more info about this, platform, minimum IOS and such?

       1 like

    • Ralph Schmieder
      Ralph Schmieder

      Hi, John. The feature has been recently introduced on the Catalyst 3k with 15.2SE / 3.3.0SE, on the 4500 with 3.5.0E and on the Catalyst 6500 with 15.1SY. I will update the post with a section that contains links to specific documents and release notes.

         1 like

  2. Zar Ni lay Thwin

    Thanks Ralph,
    Can I do this on Nexus switches as well please?

    Cheers!

       0 likes

    • Ralph Schmieder
      Ralph Schmieder

      Hi, Zar Ni. The feature is not planned for any Nexus platforms as of today. Given that those switches are primarily focused on the Data Center and this solution is more targeted at distribution and access layer networks I think this is OK. Do you have a use case for mDNS / Zeroconf in the Data Center?

      Thanks,
      -ralph

         0 likes

  1. Return to Countries/Regions
  2. Return to Home
  1. All Architect & DE Discussions
  2. Return to Home