Multicasting Apple’s Bonjour Protocol

Let’s face it. Apple’s Bonjour protocol is likely here to stay, or at-least for the foreseeable future until Apple decides otherwise. If you have an Apple device and wish to do printing or require the use of its discovery services, you will very likely encounter Apple’s Bonjour protocol. I will spare the many technical details of the protocol as a quick wiki search describes the functionality. Simply put, Bonjour is Apple’s attempt at a network service discovery protocol that utilizes multicast for its communication. Let’s get started by showing one such scenario!

The Scenario

You receive a support call one day, stating that senior management wishes to print – wirelessly, of course – from their iPhones and iPads. They are trying to print to their new Bonjour supported/enabled wireless printer, but can’t. You as the engineer investigate the functionality of Bonjour, and learn that multicast is what makes this protocol tick. A decent starting place to get configuration tips is Cisco’s Wireless LAN Apple Bonjour Deployment Guide.

Realizing that senior management is on a separate layer 3 segment across a WAN, you conclude that you’ll need to configure end-to-end layer 3 multicast in order for senior management’s Apple devices to communicate with their new Bonjour enabled printer. In this scenario, your wireless controllers (Cisco 5508’s) are separated by a WAN connection at site A from the management team at site B. Also, the wireless access points at management’s location (Cisco 1242’s) are in local mode.

Wireless clients of SSID’s for local mode access points receive their IP addressing information as though they’re on a network segment directly attached to the wireless controllers, and not necessarily from a network segment where the access points are located, even though the controller may be across a WAN connection. In contrast, clients of SSID’s of Cisco access points that are in Hybrid-Reap or the newer “FlexConnect” mode receive their IP addressing information from a network segment local to the access points.

As mentioned earlier, you will need to configure layer 3 end-to-end multicast for the Bonjour protocol to discover and communicate between the supported devices. You should start by diagramming out the network connectivity between the locations and controllers as you put together your configuration plan.

The Configuration

The high-level configuration steps are as follows:

  • Turn on and enable “ip multicast-routing” on both devices serving as routers for the layer 3 WAN connection.
  • Under the layer 3 WAN interface paragraphs for each side, you configure “ip pim sparse-mode” for the multicast discovery path.
  • Next, configure “ip pim sparse-mode” under the wireless network’s (for the SSID the Apple devices are trying to communicate on) SVI at site A, and also under the wireless access points management SVI’s at both sites A and B.
  • Knowing that Bonjour multicasts to 224.0.0.51, we need to configure the multicast rendezvous point with the necessary multicast group-list on the Site A router, as well as the multicast rendezvous point on the site B router. This is a requirement when running PIM multicast so the data can be forwarded. The rendezvous point acts as the meeting place for sources and receivers of multicast data. Once your configuration is in place the Apple devices should be able to see each other.

A Final Thought

One can only imagine that we will see Apple products become more and more popular in corporate environments. Unless Apple changes how some of their devices discover and communicate in situations as described above, encounters with Apple’s Bonjour and the need for understanding and configuring basic multicast will become increasingly common.

Bonjour to all,
Brandon

Below is the relevant configuration commands as described above for both site A and site B.

—-Site A Relevant Config—-
ip multicast-routing
!
interface Vlan100
description Wireless Network VLAN
ip pim sparse-mode
!
interface Vlan200
description WLAN Management
ip pim sparse-mode
!
interface Vlan201
description Access Point Management
ip pim sparse-mode
!
interface GigabitEthernet1/0/1
description ***WAN to Site B***
ip address 10.10.10.1/32
ip pim sparse-mode
!
ip pim rp-address 10.10.1.2 group-list 224.0.0.0/4
ip pim ssm range 232.0.0.0/8

—-Site B Relevant Config—-

ip multicast-routing distributed
!
interface GigabitEthernet1/0/1
description ***WAN to Site A***
ip address 10.10.10.2 255.255.255.252
ip pim sparse-mode
!
interface Vlan4
description Access Point Management
ip address 10.15.2.1 255.255.255.0
ip pim sparse-mode
!
ip pim rp-address 10.10.1.2
ip pim autorp listener

 

Brandon Roberson

Brandon Roberson

Brandon is a Sr. Network Engineer, focused mostly on Route Switch, Data Center, and network Security. Brandon currently works in the healthcare industry and teaches networking courses from time to time. He is currently working on his CCIE (R&S) and holds CCNP, CCDP, CCNP Security, and CWNA credentials.
Brandon Roberson

Latest posts by Brandon Roberson (see all)

  • http://twitter.com/MrsYisWhy Mrs. Y.

    Or you can just install a Bonjour Gateway, which means you won’t have to deal with PIM routing. Because troubleshooting it stinks.

  • Bob L

    Not trying to troll your post here, but is this actually working in production? The reason I ask is that Bonjour doesn’t route. Its packets have a TTL = 1. The 224.0.0.0/24 range of addresses is reserved for local traffic only. Could be that I am missing something in this post though.

    • Brandon

      Hi Bob,

      This is working in production and working well. The post is based off an actual scenario encountered. True that Bonjour doesn’t route and it’s TTL is 1. By default all multicasat datagrams have a TTL of 1. This is why you have to setup a L3 multicast path for it. With Bonjour when you L3 multicast (using PIM and an RP with-in the same Mcast network) the TTL of 1 is overlooked. I’m also running on some of the latest release’s.

      • Bob L

        OK. I was speaking from the issues I had getting it to work across network boundaries. I think maybe the key in this case was where the RP is located. Thanks for sharing.

      • James Cape

        [I'd posted a comment earlier about this, but it appears to have been eaten.]

        The address range is reserved for “link-local network control,” yes, but that’s a convention. If it does work, it only does so because the TTL is not actually set to 1 by the applications. The Linux client, avahi-daemon, sets TTL=255, for example (I don’t have a Mac here to test with).

        If TTL == 1, then the router will drop it, unless you’re specifically munging the TTL. Properly configuring PIM-SM doesn’t mean a router ignores the IP TTL.

        In any case, the best-practice way to do Bonjour on the WAN is to create unicast SRV/TXT records for your services, since Bonjour will fall back to unicast after it attempts mDNS.

  • https://twitter.com/douglashanksjr Douglas Hanks

    Turning up draft-rosen for Bonjour sounds like a great idea.

  • JeremysBrain

    Been fighting with Bonjour on my small home (read lab) network for a while. My wife wants to be able to airplay between her iPhone and the Apple TV.

    Relatively simple setup:
    Cloud
    |
    2821
    |
    3560
    | |
    2950 2500 WLC

    The 3560 handles inter-vlan routing, and the Apple TV is wired, and the iPhone is wireless, both on seperate VLAN’s. I can ping from the iPhone to the Apple TV.
    I’ve turned on multicast on the 3560, and enabled it on the SVI’s and ports. I can see the Bonjour multicast address in the WLC, but I’m clueless on the rest of the multicast setup.

    I see what Mrs. Y. is talking about!
    Any help is appreciated! I love hearing that her friends son set it up at their house, why doesn’t it work here…

  • Eric Lauriault

    When sending to the group 224.0.0.251, OSX and Apple iOS set the TTL to 255:

    16:06:09.313474 IP (tos 0x0, ttl 255, id 21878, offset 0, flags [none], proto UDP (17), length 574) 192.168.0.101.5353 > 224.0.0.251.5353: 0*- [0q] 10/0/5 98:fe:94:27:1[|domain]

    Interestingly, OSX and Apple iOS both send out igmp reports for gaddr 224.0.0.251:

    16:05:13.361579 IP (tos 0xc0, ttl 1, id 26782, offset 0, flags [DF], proto IGMP (2), length 40, options (RA)) 192.168.0.101 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 224.0.0.251 is_ex { }]

    The router (a 3560 running 15.0 in this case), on the other hand, simply drops them since they refer to a multicast group part of the local link only multicast range:

    Dec 27 2012 15:53:08.767 EST: IGMP(0): Send v3 general Query on Vlan666
    Dec 27 2012 15:53:11.845 EST: IGMP(0): Received v3 Report for 1 group on Vlan666 from 192.168.0.101
    Dec 27 2012 15:53:11.845 EST: IGMP(0): Report has illegal group address 224.0.0.251

    I am really curious as to how you actually got this to work without a Bonjour gateway. Can you show us a “show ip igmp group” and a “show ip mroute”?

    • Brandon Roberson

      Hi Eric,

      Sure here is the output from both routers.

      ****Router1 Output****

      Router1# sh ip igmp groups

      IGMP Connected Group Membership for VRF “default” – 14 total entries

      Type: S – Static, D – Dynamic, L – Local, T – SSM Translated

      Group Address Type Interface Uptime Expires Last Reporter

      224.0.1.60 D Vlan248 1d06h 00:03:56 10.101.248.5

      225.0.0.1 D Vlan248 1d04h 00:03:56 10.101.248.5

      239.1.2.3 D Vlan503 1y48w 00:02:27 10.101.53.136

      239.1.2.3 D Vlan502 41w2d 00:03:57 10.101.52.33

      239.1.2.3 D Vlan501 38w2d 00:03:36 10.101.51.160

      239.1.2.4 D Vlan503 1y5w 00:02:27 10.101.53.155

      239.1.2.4 D Vlan502 1y48w 00:03:55 10.101.52.145

      239.1.2.4 D Vlan501 1y48w 00:03:34 10.101.51.153

      239.1.2.5 D Vlan504 35w5d 00:03:51 10.101.54.19

      239.1.2.5 D Vlan502 15w1d 00:03:56 10.101.52.37

      239.1.2.6 D Vlan500 1y48w 00:03:56 10.101.50.13

      239.1.2.7 D Vlan500 1y48w 00:03:53 10.101.50.14

      239.1.2.8 D Vlan500 1y48w 00:03:53 10.101.50.15

      239.255.255.250 D Vlan248 7w1d 00:03:53 10.101.248.6

      Router1# sh ip mroute

      IP Multicast Routing Table for VRF “default”

      (*, 224.0.1.60/32), uptime: 1d13h, pim ip igmp

      Incoming interface: Vlan1, RPF nbr: 10.101.1.2

      Outgoing interface list: (count: 1)

      Vlan248, uptime: 1d06h, igmp

      (*, 225.0.0.1/32), uptime: 1d04h, igmp ip pim

      Incoming interface: Vlan1, RPF nbr: 10.101.1.2

      Outgoing interface list: (count: 1)

      Vlan248, uptime: 1d04h, igmp

      (*, 232.0.0.0/8), uptime: 1y48w, pim ip

      Incoming interface: Null, RPF nbr: 0.0.0.0

      Outgoing interface list: (count: 0)

      (*, 239.1.2.3/32), uptime: 1y48w, mrib igmp ip pim

      Incoming interface: Vlan1, RPF nbr: 10.101.1.2

      Outgoing interface list: (count: 4)

      Ethernet3/31, uptime: 7w1d, pim

      Vlan501, uptime: 38w2d, igmp

      Vlan502, uptime: 41w2d, igmp

      Vlan503, uptime: 1y48w, igmp

      (10.101.50.13/32, 239.1.2.3/32), uptime: 1y48w, mrib ip pim

      Incoming interface: Vlan500, RPF nbr: 10.101.50.13

      Outgoing interface list: (count: 4)

      Ethernet3/31, uptime: 7w1d, pim

      Vlan501, uptime: 38w2d, mrib

      Vlan502, uptime: 41w2d, mrib

      Vlan503, uptime: 1y48w, mrib

      (*, 239.1.2.4/32), uptime: 1y48w, mrib igmp ip pim

      Incoming interface: Vlan1, RPF nbr: 10.101.1.2

      Outgoing interface list: (count: 3)

      Vlan503, uptime: 1y5w, igmp

      Vlan502, uptime: 1y48w, igmp

      Vlan501, uptime: 1y48w, igmp

      (10.101.50.14/32, 239.1.2.4/32), uptime: 1y48w, mrib ip pim

      Incoming interface: Vlan500, RPF nbr: 10.101.50.14

      Outgoing interface list: (count: 3)

      Vlan503, uptime: 1y5w, mrib

      Vlan502, uptime: 1y48w, mrib

      Vlan501, uptime: 1y48w, mrib

      (*, 239.1.2.5/32), uptime: 35w5d, pim ip igmp

      Incoming interface: Vlan1, RPF nbr: 10.101.1.2

      Outgoing interface list: (count: 2)

      Vlan502, uptime: 15w1d, igmp

      Vlan504, uptime: 35w5d, igmp

      (10.101.50.15/32, 239.1.2.5/32), uptime: 1y48w, mrib ip pim

      Incoming interface: Vlan500, RPF nbr: 10.101.50.15

      Outgoing interface list: (count: 2)

      Vlan502, uptime: 15w1d, mrib

      Vlan504, uptime: 35w5d, mrib

      (*, 239.1.2.6/32), uptime: 1y48w, mrib igmp ip pim

      Incoming interface: Vlan1, RPF nbr: 10.101.1.2

      Outgoing interface list: (count: 1)

      Vlan500, uptime: 1y48w, igmp

      (10.101.50.13/32, 239.1.2.6/32), uptime: 39w5d, ip mrib pim

      Incoming interface: Vlan500, RPF nbr: 10.101.50.13

      Outgoing interface list: (count: 1)

      Vlan500, uptime: 39w5d, mrib, (RPF)

      (*, 239.1.2.7/32), uptime: 1y48w, mrib igmp ip pim

      Incoming interface: Vlan1, RPF nbr: 10.101.1.2

      Outgoing interface list: (count: 1)

      Vlan500, uptime: 1y48w, igmp

      (10.101.50.14/32, 239.1.2.7/32), uptime: 50w1d, ip mrib pim

      Incoming interface: Vlan500, RPF nbr: 10.101.50.14

      Outgoing interface list: (count: 1)

      Vlan500, uptime: 50w1d, mrib, (RPF)

      (*, 239.1.2.8/32), uptime: 1y48w, mrib igmp ip pim

      Incoming interface: Vlan1, RPF nbr: 10.101.1.2

      Outgoing interface list: (count: 1)

      Vlan500, uptime: 1y48w, igmp

      (10.101.50.15/32, 239.1.2.8/32), uptime: 01:08:03, ip mrib pim

      Incoming interface: Vlan500, RPF nbr: 10.101.50.15

      Outgoing interface list: (count: 1)

      Vlan500, uptime: 01:08:03, mrib, (RPF)

      (*, 239.255.255.250/32), uptime: 7w1d, igmp pim ip

      Incoming interface: Vlan1, RPF nbr: 10.101.1.2

      Outgoing interface list: (count: 1)

      Vlan248, uptime: 7w1d, igmp

      Router1#

      ****Router2 Output****

      Router2#sh ip igmp groups

      IGMP Connected Group Membership

      Group Address Interface Uptime Expires Last Reporter Group Accounted

      239.1.2.3 Vlan2 7w1d 00:02:26 10.102.2.135

      224.0.1.40 GigabitEthernet1/0/4 7w1d 00:02:31 10.102.255.2

      Router2#sh ip mroute

      (*, 239.1.2.3), 7w1d/stopped, RP 10.101.1.2, flags: SJC

      Incoming interface: GigabitEthernet1/0/4, RPF nbr 10.102.255.1

      Outgoing interface list:

      Vlan2, Forward/Sparse, 7w1d/00:02:15

      (10.101.50.13, 239.1.2.3), 7w1d/00:02:54, flags: JT

      Incoming interface: GigabitEthernet1/0/4, RPF nbr 10.102.255.1

      Outgoing interface list:

      Vlan2, Forward/Sparse, 7w1d/00:02:15

      (*, 224.0.1.40), 7w1d/00:02:19, RP 0.0.0.0, flags: DCL

      Incoming interface: Null, RPF nbr 0.0.0.0

      Outgoing interface list:

      GigabitEthernet1/0/4, Forward/Sparse, 7w1d/00:00:00

      Router2#

  • Peter

    Here is why this works:

    In local mode, access points tunnel their Multicast Traffic over the CAPWAP tunnel to the controller. – Multicast routing is required at the controller for this to play nice, as always.

    There are two operating modes to handle multicast traffic from the controller to local mode WAPs and back again:

    1. Unicast mode. Effectively, the controller takes all multicast traffic and tunnels it in unicast packets to the access points. This is bandwidth inefficient for obvious reasons.

    2. Multicast mode. In a nutshell, the multicast traffic, regardless of originating stream address, is sent to the WAPs via a pre-defined multicast address. This stream does not match the TTL of the underlying multicast stream.

    So, in a nutshell, your Bonjour traffic gets encapsulated in either a unicast packet to and from the controller or gets encapsulated in a multicast stream that has different rules. This is how we are able to traverse VLANs in a distributed-routing environment.

    Note that in this setup, all Bonjour traffic is still originating from the same subnet, even though we are on different parts of the WAN.

7ads6x98y