Why Bonjour Hates my Wireless Network
Many of you know my struggle as of late to integrate all of my recently acquired Apple devices into my existing network. Many of you also know the frustration I’ve had with this process and have been innocent passers-by to my incessant twitter updates, rants and spontaneous bursts of misplaced anger. Here then, is my brief explanation of what the problem is, and why I now—after too many rabbit-hole adventures to list—believe that I will not solve my problem without different equipment or a radical re-design of my network.
I should point out, by the way, that it’s not that I’m a masochist—really I’m not—but rather that in my studies I find it useful to have a lot of equipment lying around. That equipment inevitably works its way into my home network, and after some time I have a large and sometimes convoluted structure in place. In this case, however, the wireless is pretty far outside the scope of anything I’ll deal with on the CCIE Routing and Switching Lab Exam, and was brought in specifically to support some future upgrades to my home: wireless security, roaming VoIP phones, etc. The irony, as my wife so perfectly pointed out the other evening, is that if we just had a “regular” little wireless router “like all the normal, non-computer geek people” our Apple devices would all work.
If you haven’t read my previous posting on Bonjour, that might provide some more background but isn’t, strictly speaking, necessary. Some understanding of Bonjour might be helpful, however, so very quickly, here it is: Bonjour is Apple’s implementation of a service discovery protocol similar to Microsoft’s zero-conf. It uses a couple of addresses to make things work, and it is the protocol behind Apple’s “everything just works” magic. If you want more than that, Google can offer you much deeper explanations.
Bonjour uses two addresses, really, to do its work: 220.127.116.11 and 18.104.22.168, the latter of which is the “discovery” part of the protocol and the former where the action happens. The astute among you will notice that these are both link-local addresses and so won’t be forwarded by layer‑3 devices (even really, really broken ones) at all. I had already been around the block with this once before, and so figured that because my wireless network was one broadcast domain (thought I smugly) everything would be all good. I was wrong.
Now would be a good time to toss in a quick network diagram so that you can visualize what we’re talking about here. The drawing below is just the wireless portion of my network as it applies to what we’re discussing in this article. Rest assured, there is a lot more out there, but none of it is applicable to this situation.
As you can hopefully see, we have a 2811 ISR connected to a 2950 switch via 802.1q, and two 1142 APs connected at layer‑2 to the switch. What might not be as obvious at first is that the Wireless Lan Controller you see at the upper right of the diagram is a module sitting in the 2811 router. This is where the heart of evil apparently lies, but more on that in a minute. The access points are on VLAN 16, and get DHCP assignment from the 2811 along with option 43 and option 60 which are both necessary (despite what you may hear) to get the radios registered to the controller, at least in this configuration. All VLANs are allowed everywhere (for testing) and no ACL/VACLs or any other security outside of standard wireless is applied.
Before anyone points out the obvious, by the way, I did reconfigure this arrangement to put the APs on the same VLAN as the WLC management interface, make that the native VLAN all the way through, and bridge the switch and router at layer 2 with BVI, just as a test to eliminate layer‑3 boundaries. While interesting to do, that didn’t solve the problem we’re having here. In fact, I didn’t even notice the real problem location until I made this diagram (who would have thought?).
The WLC modules that plug into a router, while running the same software and otherwise operating almost identically, are different in at least one key respect from their stand-alone counterparts: they can’t communicate at layer‑2 with the router. A standard controller (say a 4400 series) can communicate at layer‑2 with radios plugged in to access switches, thereby becoming the first layer‑3 hop from the radios—even when different VLANs are assigned than management. The integrated module, however, communicates with the host router across the backplane at layer‑3. Looking back at the diagram, you can clearly see that drawn out. So no matter what I do with bridging from the radios, switch, router, etc., inevitably I’ll have layer three separation between the radios and the controller.
This is all well and good for most protocols, but not for link-local multicast.
I think I found every rabbit-hole possible to get lost down, and proceeded to do just that. When I finally ran out of said holes to explore, kind folks on twitter that I respect and look up to sent me off in still more directions. I tried, in no particular order:
(1) Using Destination NAT to change the 22.214.171.124 and 252 addresses to multicast in the 239.x.x.x range
(2) Using Destination NAT to change the 126.96.36.199 and 252 addresses to unicast
(3) Using helper maps
(4) Bridging everything under the sun to everything under the moon. No love because the backplane can’t be bridged.
I was going to even try GRE tunnels, DCI, or any other type of tunnel to move Layer‑2 over Layer‑3. At the end of the day, however, besides getting tired of the project, I decided that nothing was likely to work. Why? Because one of the first things a layer‑3 device does when it receives a packet is to decrement the TTL. So no matter what I do with NAT, or tunnels, or any other damned thing, the router will always decrement the TTL before it decides to pass the packet to some other service (like DNAT, GRE, whatever), thereby discarding the packet before it ever reaches those processes.
As far as I can tell today, this is unsolvable. Apple hates me, and others like me. Using a TTL of 1 as your method of locking down communications is pretty rock-solid from a DRM viewpoint, but also very inflexible and heavy-handed. I’m going to put a portable 3560 in my entertainment center to support my DirecTV box, Apple TV and other entertainment devices so that they can share the iTunes library on my main computer, but I’m not happy about it. I lose my shiny N‑connected coolness, and my iPad won’t be able to control those devices. In addition, I’ve had to hard-set my wife’s printer, since her Mac can’t find it any more.
The bottom line is that all of the auto-configuration magic that Apple devices can have has gone away in my current set up. I could fix it by running a parallel wireless network using autonomous access points, or buy a cheap‑o wireless router, but then I have the other problem where I lose visibility and control, just to make a quirky system work. The only viable option, really, is to change out my WLC module for a stand-alone controller—which I may do at some point—but at this point I’m tired and may just move on, defeated.