Cisco Service Discovery Gateway – Enabling Zeroconf in Enterprise Networks

I’ll admit it: I’m what others call an Apple fan boy. One of the many reasons for being one is the polished user experience and the ease-of-use of their products. One of the underlying technologies that enables the user to discover devices and services on the network is Zeroconf or, as Apple calls it, Bonjour.

Zeroconf consists of three major components:

• Address auto configuration,
• Naming –and–
• Service discovery.

If your network doesn’t have a DHCP server or you haven’t statically assigned an IP address to your host, most operating systems will use an automatic private IP address. I’m not going into much detail on address auto configuration except that this is typically done using a technique called APIPA (Automatic Private IP Addressing) for IPv4 the host will use the famous 169.254.0.0/16 addresses or, in case of IPv6, by using link-local addresses only (FE80::/10) which has been designed into IPv6 as a basic functionality from day one. Also, naming is not of much of a concern in the context of this discussion. However, it is worth mentioning that Zeroconf names can contain Unicode characters and whitespace, which can make those names a lot more user friendly and meaningful contrary to pure DNS names.

The more interesting part, as it pertains to Zeroconf, is the service discovery. Service Discovery enables finding services like printers, speakers, cameras, displays and more without knowing their address or other details of the service. We just ask for a service (“I want to print!”) and the device providing that service is answering our question directly, no intermediate facilitator or central service directory required.

Service Discovery Explained

So, how does this work? Service Discovery uses link-local multicasts to announce and query for services that exist on the local network. By its very nature, link-local multicast advertisements will not be forwarded beyond the local segment (VLAN, Switched Virtual Interface or routed port). We will learn about services within our own local segment but when a device is connected to a different segment we won’t be able to discover it.

However, just because we can’t discover that service does not mean that we cannot talk to it. For that matter, Service Discovery is similar to a phone book: When we want to look up the phone number for a particular person that person may be listed in our local phone book and if not, we may need to look them up in a larger directory listing. If the person is listed in the phone book we can try to call them. The phone book look up is then equivalent to Service Discovery (it happens on the ‘control plane’).

Whether it is possible to get through to this particular person or not (comparable to Caller Screening) is a different question. Again, the same is true for Zeroconf: Even though we now know the address of that printer, we might be blocked to access it by policy. This is then referred to as the ‘data plane’. It is also true in the opposite way. If the person we want to talk to is not listed in the phone book, we still might be able to call them because we know their phone number.

This is especially important to understand since certain services might be discoverable but the service still can’t be used because access to the service might be restricted, specifically if the device providing the service and the client asking for the service are not on the same link. RAOP (Remote Audio Output Protocol/Audio Streaming by iTunes) is such an example.

Introducing IOS Service Discovery Gateway

Here in Orlando for Cisco Live! we introduced a new component in IOS which allows us to extend Service Discovery beyond the link-local scope by implementing a proxy and redistribution component in IOS called Service Discovery Gateway. In its simplest form it will be enabled globally and it will listen for and learn services on all L3 interfaces of the router. These services will be added to a cache and whenever a device (PC, Smartphone, …) asks for a service, the router will look up that service in its cache and when it finds a match it will respond in a proxy-like fashion. This technology has the capability to apply service filters so that information in the cache can be controlled and service visibility can be limited, if required. A typical example of such a policy on the service gateway could allow printer services but denies remote audio streaming or music sharing.

Configuration Example

As described above, enabling service routing is very simple: define a ‘permit all’ service list, enable service routing globally and apply the service list. The accompanying CLI looks like this:

service-list mdns permit-all permit 10
service-routing mdns
service-policy permit-all in
service-policy permit-all out
redistribute mdns-sd
!

When this basic configuration has been enabled on the router, it will learn about services on all attached L3 interfaces (VLANs) and fill its cache with service instances. It will also respond to service queries and act as a man-in-the middle for clients and servers living on different subnets attached to that router.

Cisco Live Demo Booth

As part of the Cisco ONE booth we had a pod to demonstrate the IOS Service Discovery Gateway and customer interest in the demo and the solution overall was very high. Customers really liked the added capabilities and versatility that this component adds to IOS. The problem (specifically allowing wireless clients in a particular subnet access to wired services like printers and displays located on a different subnet) is apparently quite common and the added benefit of tailoring services with filters and transparency of operation, if desired, was highly appreciated by attendees who saw the demo.

Interested in learning more? Ask us your questions at the upcoming Cisco TechAdvantage Webinar: Supporting Zeroconf and Apple Bonjour in the Enterprise using Cisco’s Service Discovery Gateway on Wednesday, August 7th at 8am PST. Looking forward to it!