April 23, 2012

Don't Bid 'Adieu' to Apple Bonjour Just Yet

Apple iPhones and iPads continue to be among the most popular devices joining  enterprise wireless networks. In some cases, enterprises themselves are deploying, top down, large populations of Apple devices; in other cases, users are bringing their personal devices into the enterprise and expect connectivity to corporate resources.

Much has been written about the issues associated with the shift from corporate-liable mobile devices to employee-liable (personally procured) ones. But one big issue for Apple devices in particular - regardless of who introduces them into the organization - is Apple's limited-reach, yet bandwidth-greedy Bonjour service advertisement, discovery and resource-sharing protocol.

Say Hello to Bonjour

WirelessTN-April-23-ART.jpgA mobile client device running Bonjour can locate and use local peripherals such as printers, projectors and Apple TV receivers and the services that these devices offer. To reveal the available services, Bonjour uses multicast Domain Name System (mDNS) service records. But like other aspects of the Apple mobile environment, such as the IOS 5-based Siri voice-response application and iCloud backup and synchronization service, Bonjour heaps loads of overhead onto bandwidth-constrained Wi-Fi networks unless somehow tamed.

In the home with one, or possibly or two, Wi-Fi access points, printers, Apple TV receivers and so forth, the multi-discovery capabilities of Bonjour are a non-issue. Imagine, though, a client device sending service-discovery messages everywhere across a large enterprise network and receiving "I'm here!" messages back from all the available devices and services. In an enterprise context, that could create quite a heavy network load.

For this reason, the most common enterprise strategy for dealing with Bonjour has been to disable it. Admittedly, there's probably a whole business case that could be made for creating new companies to solely focus on the problem of correcting Apple devices' behavior over bandwidth-limited wireless networks. In this case, anyway, at least two existing Wi-Fi vendors have stepped up to the plate to make Bonjour a tad more enterprise-friendly.

Aerohive Networks recently introduced the Bonjour Gateway, which its says enables Bonjour to traverse multiple subnets and thus advertise services more thoroughly across enterprise nets. For its part, Aruba Networks has announced AirGroup software to stem the flooding of Bonjour traffic on wireless nets. Both vendors' software will be available at no charge to existing customers and can work on other Wi-Fi vendors' wireless LAN infrastructures.
 
Parallel Problems

The two solutions might at first seem at odds, but they're really not. The first thing that's important is users' ability to see - so they can use - what peripheral resources are available to them. In its native form, Bonjour operates at Layer 2 and thus can't see beyond a Layer 3 subnet, which most enterprises have in place. That restricts use of the resource-advertising service to only that one network domain, which doesn't work when users are highly mobile. That's the problem Aerohive addresses with its gateway, currently scheduled to ship mid-year.

By the same token, in advertising resources across the whole network, you want to streamline unnecessary exchanges of service-discovery messages for the excessive overhead mentioned. Let's say you're a mobile worker in a large company with 500 printers spread across multiple buildings, and you want to print a document. Do you really need to see the location of all 500 printers or just a couple that are near where you are at the moment?

Probably the latter. But because you might be anywhere in the enterprise or campus, the service visibility needs to reach across the whole network. From there, visibility in the user's temporary domain needs to be limited to those peripherals and services he/she is likely to use to keep the experience user friendly and streamline network overhead. That's the problem Aruba purports to solve.

Policies for Home, School, Work

Consider, for example, a university setting. Students want to use Apple's AirPlay service to stream content from their laptops to an Apple TV receiver for output on a high-def TV that's probably in their dorm room or in a nearby student lounge. If a student should make the request and content is streamed to all such devices all over campus, that's a lot of unnecessary flooding.

Also, what if a student has his own AirPrint-capable printer but doesn't want it to show up on the entire student body's Bonjour services list? There's a way with the Aruba solution, scheduled for availability this fall, to register that device as "personal."

And as mentioned, at home, the number of peripherals is likely limited. So there's not much need to control Bonjour's brutish behavior there.



3 Comments

The lack of a service name protocol has long been an issue with IP networking. This was the second big advantage IPX (for those who remember dead protocols) had over IPv4. (The first was a bigger address space.) A well configured IPX network could route service advertisements across the country, and do it efficiently.

But IT really doesn't see the need for a service like this; somehow they think only those services deemed important enough to configure manually are important. This leaves networks at risk to the crushing burden of constant manual updates and being constantly out of date.

Bonjour is similar to the excellent Service Location Protocol (SLP), which appears to be withering due to inattention. So, it looks like we will let SLP die, choke off Bonjour and stub our toes in the metaphorical dark of the lack of visibility on our networks.

Hey Joanie! I don't think the article above accurately depicts what the Aerohive Bonjour Gateway can do – it seems to imply we don't support filtering, which is a key part of our solution. Not only can we "help" the protocol by bridging advertisements and discoveries across subnets, but we also allow an administrator to create service-specific filters between VLANs - the root of location - and devices to limit exactly what services (such as AirPrint or AirPlay, or even just low-bandwidth audio but not video) are available to and from which devices and users. You can see a demo of our Bonjour capabilities today by visiting the Aerohive blog page, or test it out by signing up for the beta! :–)

The capabilities that Aerohive and now Aruba have introduced to propagate Bonjour over distributed WLANs reminds me of what IPsec VPN vendors did long ago to propagate NetBIOS broadcasts to remote subnets interconnected via VPN.

VPN-connected remote office Windows users couldn't "see" file shares and network printers located at other VPN sites, because NetBIOS name resolution broadcasts were not routable. To help work around this, some VPN vendors added settings that admins could enable to propagate NetBIOS broadcasts over VPN tunnels. This helped remote users locate and connect to centralized file shares, etc. But just relaying LAN broadcasts throughout a VPN like this isn't very efficient.

As Abby notes, what Aerohive has done goes well beyond relaying broadcasts. First, granular policies control which Bonjour multicast DNS discoveries and advertisements get propagated between WLAN segments. Second, these Bonjour Gateways don't just relay broadcasts - they actively participate in network service advertisements, reducing total # of broadcasts. The result should be far more efficient and also let WLAN admins directly control and tune how much Bonjour gets used.

I don't know how big a role Bonjour will ultimately play in the enterprise, but a gateway like this at least makes using Bonjour in the enterprise technically feasible while addressing performance and security needs.

Search Webtorials

Get E-News and Notices via Email


  

 



  

I accept Webtorials' Terms and Conditions.

Trending Discussions

See more discussions...

Featured Sponsor Microsites






















Archives

Notices

Please note: By downloading this information, you acknowledge that the sponsor(s) of this information may contact you, providing that they give you the option of opting out of further communications from them concerning this information.  Also, by your downloading this information, you agree that the information is for your personal use only and that this information may not be retransmitted to others or reposted on another web site.  Continuing past this point indicates your acceptance of our terms of use as specified at Terms of Use.

Webtorial® is a registered servicemark of Distributed Networking Associates. The Webtorial logo is a servicemark of Distributed Networking Associates. Copyright 1999-2018, Distributed Networking Associates, Inc.