Extending Zeroconf Services: Cache Tuning

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).

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.

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:

• Permit any queries. This is important to discover services from the cache.
• Permit specific announcements (printers, Apple TVs, but no client machines). If there are devices on this segment that should be known in other segments, then the service(s) they provide need to be explicitly exempt.
• Deny everything else. This means that we specifically prevent the cache from learning client services.

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

• At-a-Glance Document
• Release Notes for Catalyst 3k & 4k
• Release Notes for Catalyst 6500
• Configuration Guide (for the 3850, but most of it is applicable for the other platforms as well)