Cisco Wireless LAN Controller Bonjour Phase IV Deployment Guide, Release 8.1
Available Languages
Table of Contents
Cisco Wireless LAN Controller Bonjour Phase IV Deployment Guide, Release 8.1
Bonjour Services in Phase I and II — Release 7.4-7.6
Introduction to Bonjour Policies and New Requirements
Device Access Policy Constructs and Rules
Client Context Attributes in an mDNS Policy
Configuring mDNS Bonjour Policies
mDNS Profile Attached to Local Policies
Use Cases for mDNS Bonjour Policies Deployments
Cisco Wireless LAN Controller Bonjour Phase IV Deployment Guide, Release 8.1
For configuration and information on the previously released Bonjour features, refer to the following deployment guides:
http://www.cisco.com/c/en/us/td/docs/wireless/technology/bonjour/Bonjour74.html
http://www.cisco.com/c/en/us/td/docs/wireless/technology/bonjour/7-5/Bonjour_Gateway_Phase-2_WLC_software_release_7-5.html
http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/WLAN-Bonjour-DG.html
Overview
Bonjour is an Apple service discovery protocol, which locates devices such as printers, other computers, and the services that those devices offer on a local network using multicast Domain Name System (mDNS) service records. The Bonjour protocol operates on service announcements and service queries, which allow devices to ask and advertise specific applications such as:
■
iTunes Wireless iDevice Syncing (in Apple iOS v5.0+)
■AirPlay offering the following streaming services:
–Music broadcasting in iOS v4.2+
–Video broadcasting in iOS v4.3+
–Full screen mirroring in iOS v5.0+ (iPad2, iPhone4S or later)
Each query or advertisement is sent to the Bonjour multicast address for delivery to all clients on the subnet. Apple’s Bonjour protocol relies on mDNS operating at UDP port 5353 and sent to the following reserved group addresses:
■IPv4 Group Address – 224.0.0.251
■IPv6 Group Address – FF02::FB
The addresses used by the Bonjour protocol are link-local multicast addresses, and thus are only forwarded to the local L2 domain. Routers cannot use multicast routing to redirect the traffic because the time to live (TTL) is set to one, and link-local multicast is meant to stay local by design.
Bonjour Services in Phase I and II — Release 7.4-7.6
Prior to release 8.0, the following features were introduced in the Phase 1 and 2 of the Bonjour services support on the CUWN. These features include the following:
■Location Specific Services (LSS) for wireless service
■mDNS-AP (enhance VLAN visibility at WLC for non-layer 2 VLANs)
■Origin based service discovery
Table 1 lists the services that are offered in phases 1, 2, 3, and 4.
Introduction to Bonjour Policies and New Requirements
Enterprise credentials of Bonjour are poor and hence the advent of Bonjour gateway. Bonjour gateway snoops and caches Bonjour services across VLANs and periodically refreshes the same. WLC acts as a proxy for all Bonjour services published by wireless and wired devices. Bonjour gateway as of release prior to 8.0 had inadequate capabilities to filter cached wired / wireless service instances based on the credentials of the querying client and its location.
With introduction of the Bonjour policies in the release 8.0, the administrator can configure to identify who uses the Bonjour service instances and in what location (all this applies to the same WLAN). With introduction of the Bonjour policies, the administrator does not need to create multiple WLANs to select which services are allowed or should be used on specific WLAN. Based on user 802.1x authentication, the AAA server or ISE can be configured to return USER-ROLE or BONJOUR-PROFILE in the form of the “CISCO-AV-PAIR”. This value gets plumbed into the policy created on the wireless controller. Based on the user authentication, a configured policy and profile are applied to a specific user on the same WLAN.
As mentioned in the figure above, improvements to Bonjour services are made, and Bonjour policies are introduced to allow per service instance (MAC address) configuration that mandates how the service instance is shared, which is articulated as follows:
■Service instance is shared with whom (user-id).
■Service instance is shared with which role/s (client-role).
■What is the location allowed to access the service instance (client location).
This configuration can be applied to wired and wireless service instances, and the response to any query will solely be based on the policy configured for each service instance. This allows selective sharing of service instances based on the location, user-id, or role. Since most service publishing devices are wired, this allows filtering of wired services at par with wireless service instances. While mDNS profile associated with the client checks for service type being queried before responding to the query, the access policy further allows filtering of specific service instances based on querying client location, role, or user-id.
With Bonjour access policy, there are two levels of filtering the client queries, which are as follows:
■At the service type level by using the mDNS profile.
■At the service instance level using the access policy associated with the service each instance.
A service instance or a set of service instances discovered and cached by the WLC can be associated with an access policy filter, which acts like a lens that determines which clients and what kind of client context (role or user-id) can see and access the service instance.
Note: Service instances that are not configured with any access policy will be mapped to the default access policy, which allows only the administrator user role, by default, to receive the service instances. Additional users can be configured and added in the default policy.
■Bonjour access policy filters can be configured for specific service instances identified by the MAC address of the devices publishing the services.
■Bonjour access policy is associated with a service group name that contains one or more MAC addresses of the devices publishing the Bonjour services.
■The service group name is then attached to the service instance when it is discovered and cached at the WLC.
■While traversing the list of service instances in response to a client query, each instance will be evaluated to verify if the querying client location, role, or user-id are allowed access to the service instance before including the same in the response.
If the same MAC address is configured in multiple service groups, it means the service instance will be associated with all the service group names that are configured with this MAC address, and all the access policies associated with the MAC addressee’s service group names will be evaluated until the verdict is to include the service instance. Currently, a maximum of five service groups are supported for a single MAC address. Service group configurations can be done even when mDNS snooping is disabled or offline, and the access-policy comes into effect when the services are discovered. It can also be done dynamically when snooping is already enabled.
Bonjour Service Groups
A service group name can be associated with a set of MAC addresses, and the maximum MAC addresses that can be configured for any service group is limited by the platform dependent global maximum number of service instances that can be discovered, that is,
In release 8.0, service limit: 6400 on 2500, 5508, WiSM2 and vWLC and 16000 services on 7510 and 8510 UC Controllers.
In release 8.1, the service limit has changed to be more reflective of number of the AP licenses and clients supported and will change accordingly on 5508 and WiSM-2 controllers.
As shown in the table, in release 8.1, 5508 controller is scaled down to support only 1000 services at full scale (500 APs and 7000 clients). With 80% scale (400 APs and 5400 users), the same 5508 controller supports 2400 services. Similarly, WiSM-2 supports 2000 services at full scale (1000 APs and 15000) and 4800 services at 80% scale. Number of Bonjour services remains unchanged on the 7500 and vWLC controllers. 5520 and 8500 series controllers support 16,000 services in release 8.1.
Each MAC address is configured with a unique name, which can be the service instance name, and the location of the MAC address for both wired and or wireless.
1. Since flexibility is desired when configuring the location using the AP-NAME, AP-GROUP, or AP-LOCATION, the administrator has to configure the type of location that is desired. This configuration implies that only clients from the same location as that of the device publishing the service can access the service. As long as the global maximum limit of MAC addresses is not exceeded, any service group can configure as many MAC addresses as desired.
In case of wireless service instances, the device location can change. Yet, if you want only those devices whose location is same as that of the service instance, the keyword “same” could be configured for such wireless service providers.
In case of wired services, the same location does not apply because wired clients do not get associated to the AP.
2. If the keyword “Any” is configured for location, it implies that there is no location based filtering for the clients trying to access the device. This means the clients from any location can access the service subject to role and user-id credentials being allowed by the policy associated with the service group for that MAC address.
3. If the keyword “ap-name” is used, only clients associated to that AP can access the service instance.
Note: Location validation is implicit and will be the first level of access policy filtering even before ROLE and USER-ID credentials of the client are verified.
Table 2 depicts a possible policy configuration with the service group named AppleTV-teachers.
Device Access Policy Constructs and Rules
This section explains the access policy in terms of the client context attributes, its constructs, the rule components that make up of the policy, and how the rules and hence the policies are evaluated. This helps in deciding whether the given service instance should be included or not in the mDNS response for the client that made the mDNS query. Further, if multiple service instances are mapped to the same access policy, for a given mDNS query, the policy will be evaluated only once for all those instances which have the same access policy mapping to optimize the policy evaluation overhead for a given query.
Client Context Attributes in an mDNS Policy
Any client initiating an mDNS query can be associated with a set of attributes that describe the context of the client. The attributes, for example location, can change dynamically when the clients move to a different location. Only these enumerated attributes will be used to articulate a Bonjour access policy rule. The list of attributes and how they are fetched are detailed in Table 3. The user can formulate a rule by combining these attributes with logical OR operations and attach the rule to the policy. A policy is composed of a single rule, even though multiple rules can be provisioned.
Access Policy Rules
An access policy service group is identified by a name and is associated with just one rule.
The rule is defined using the role or user-id (comma separated list). It implies that, a client, making an mDNS query, whose role is one of those listed in the policy roles or the client user-id is one of those listed in the user-id list, then access to the service instances is granted.
[ROLE=teacher, student] AND [USER-ID = John, Mike]
Configuring mDNS Bonjour Policies
To configure the mDNS Bonjour policy on the controller, perform the following steps:
1. On the Controller tab, in the left pane, click mDNS > General.
2. In the right pane, in the Global Configuration area, check the mDNS Global Snooping and mDNS Policy check boxes.
The same operation can be accomplished from the CLI with the command:
Wlc > config mdns policy enable
3. To configure the mDNS Service group, do the following:
a. On the Controller tab, in the left pane, click mDNS > mDNS policies.
b. In the right pane, click Add Group.
c. In the Add New mDNS Service Group area, enter the group name and description for the mDNS service group.
The same operation can be accomplished from the CLI with the command:
Wlc> config mdns service-group create
4. Once the service group is created, configure the service group with service instances in that group, such as who can use those services and in what location. See examples of configuration from GUI where ATV-teacher group is configured.
You can choose Location Type by AP Group, AP Name or AP Location.
5. Configure Location as ANY, SAME or by AP-NAME. Location AP can selected based on the AP Name configured as shown in the following example.
a. If keyword Same is selected, it implies that only clients from the same location as that of the device publishing the service can access the service. As long as the global maximum limit of MAC addresses is not exceeded, any service group can configure as many MAC addresses as desired.
In case of wireless service instances, since the device location can change, and yet we want only those devices whose location is same as that of the service instance, the keyword Same could be configured for such wireless service providers.
In case of wired services, the same location does not apply because wired clients do not get associated to the AP.
b. If the keyword Any is configured for location, it implies that there is no location based filtering for the clients trying to access the device. Meaning, clients from any location can access the service subject to role and user-id credentials being allowed by the policy associated with the service group for the mentioned MAC address.
c. If the keyword AP-Name is used, only clients associated to that AP can access the service instance.
Finally, as explained, the policy rule must be configured with users Role and optionally with user-id. Also, the user ROLE has to be configured to match the ROLE av-pair string that will be returned from the AAA server upon user’s successful authentication. As shown in the example below, the Role Name teacher has to be matched to use that service group.
The mDNS service groups are listed after being created.
Note: There is a default-mdns-policy group that contains all the service instances that are not configured in all other groups. Only the administrator has access to those instant services unless other users are added in the default mDNS policy.
6. Configure the AAA server or ISE to allow users to be 802.1x authenticated and have the AAA server send the ROLE string back to the wireless controller.
As illustrated below, on ISE, configure users, that is, teacher1 and student1. and groups, that is, group teachers and students.
Also configure groups, that is, group teachers and students.
7. Create an ISE policy for a specific group of users with a desired role, that is, student or teacher.
This creates a cisco-av-pair with a role attribute as student or teacher. Below is an illustration of the cisco-av-pair with a role attribute “student” that has been created.
As a result, a user with “role = student” will be allowed to use service instances, that is, “bonjour-student” but other would not be able to access the service instances. Also, a user with
“role = teacher” will be allowed to use service instances configured in the mDNS Service group with role = teacher or student.
8. The administrator can also create multiple mDNS profiles on the WLC and override them based on user authentication. The mDNS profile can be user specific and be overridden with AAA “av-pair=mDNS-profile-name” returned to WLC from AAA server that overrides default profile.
The following figure illustrates profile names that are configured on the wireless controller.
The profile names can be overwritten with a profile based on a configuration for a specific user per their AAA credentials as illustrated below in the ISE configuration example.
The figure below shows the ACS server configuration.
mDNS Profile Attached to Local Policies
Just like all clients associated with a WLAN pick the same Bonjour profile and allow the services configured for the profile, a Bonjour profile can be attached to a local policy for a client with a particular device type and ensure that each policy can be configured with a different mDNS profile name to restrict the policy from being able to use the services allowed by the profile. Eventually, the device gets access to the service instance based on the access policy tagged to the specific service instance. So there are two levels of filtering:
■Local policy just decides / controls if the service type is allowed or not.
■Bonjour access policy for the specific service instance will eventually decide if the client can use the service.
The administrator has an option to bind or enforce a specific profile to a local policy. Bonjour profile can be attached to a local policy for a client with a particular device type. This allows each local policy to be configured with a different mDNS profile name and to restrict the user from being able to use the services allowed by the profile.
In the following example, Local Policy limits the users with role “teacher” to using Service Group instances on the Apple iPhone devices.
Use Cases for mDNS Bonjour Policies Deployments
To better understand the Bonjour Policies introduced for the controller release 8.0 and their deployments, several use cases have been created to demonstrate deployment examples of the new policies implementation. The profiles can be created and applied to the WLAN, but all rules applied in the profile are applied to all users regardless of their roles or location. With introduction of policies, the administrator can configure different rules to be applied for the 802.11x authenticated users based on their Role, Name, Location or Device they are using.
For the purposes of the configuration, let us use the following examples of the Use Cases.
USE Case #1 Deployment
Teacher, Student, and Guest on the same SSID with WPA2/802.1x.
As mentioned in the Configuring mDNS Bonjour Policies section, do the following to deploy the use case:
1. On the Controller tab, in the left pane, click mDNS > General.
2. In the right pane, in the Global Configuration area, check the mDNS Global Snooping and mDNS Policy check boxes to enable the mDNS gateway services on the controller. This enables the Bonjour policies on the controller. Also, under services, ensure to enable desired Apple services for the controller to snoop.
3. On the Controller tab, in the left pane, click mDNS > Profiles, and check that at least one mDNS profile is available.
Note: The “default-mdns-profile” is configured with all main Apple services. As indicated in the earlier section, only one mDNS profile can be enabled per WLAN.
4. On the Controller tab, in the left pane, click Interfaces, create dynamic interfaces, and map services to those interfaces or VLANs. Ensure that you have Apple services on the interface other than management.
5. After connecting Bonjour services such as Apple TV, Printers, and Reflector services, check that all the services are listed in the Domain Names area on the Controller tab.
6. Configure WLAN for services with WPA / PSK and also another WLAN for clients with 802.1x, activate the AAA server or ISE.
8. Enable mDNS snooping on the WLAN and bind it to an mDNS profile.
9. After general configurations for the mDNS are complete, configure Bonjour policy so that the following occurs upon users authentication:
a. Teacher authenticates and gets access to Reflector, Apple TV1, and Apple TV2 in any location.
b. Student authenticates and gets access to only Apple TV1 in any location.
c. Guest authenticates and gets no access to any Bonjour service.
10. Create mDNS service groups under Controller > mDNS Policies.
11. Create Bonjour policy for teachers as required in the case study. To add service instances to the list, use the Domain Names area to obtain MAC addresses for each specific service.
12. Create Bonjour policy for students as required in the case study #1.
Use Case #2 Deployment
To configure the policy, perform the following steps:
1. Configure a policy for the teacher to be able to access Apple TV1 and Apple TV2 only in one location next to one specific AP. In this case, the AP name is AP2600-8aba.
2. Choose the MAC addresses of both Apple TVs from the domain name summary, and manually enter them as shown in the figure above.
3. Also choose APs, that is AP names, from the list of the APs in the desired location. Only wireless clients connected to these selected APs will have access to the desired Apple TV services.
Once the configurations of the two policies for this use case are completed, they will look as in the figures below.
When the teachers login and only attached to the AP2600, they will see the services available to them in that specific location only. The below services also show Reflector service – it was done just for the purpose of taking screenshots. Last example is for the Guest user.
As shown in this use case, the teacher has access to Apple TV 1 and Apple TV 2 in specific location. Student, based on the policy designed, has access to only Apple TV2 in specific location. Guest User does not have access to any services on this WLAN.
Debugging Bonjour
Following are the commands to debug Bonjour:
The above debugs are enhanced for the new features also.
Bonjour browser and “show mdns service not-learnt” could be used as a debug tool as well.
Bonjour browser
■Bonjour browser is a cache of all the service advertisements seen at the WLC and not discovered because configuration did not allow learning.
■Service advertisements across all VLANs and ORIGIN types that are not learnt are displayed.
■Bonjour browser is a cache of top 500 entries.
■The user can add services by picking them from the Bonjour browser instead of typing the string.
Bonjour SSO
Any mDNS configuration performed on the Active WLC will be synced up on the standby WLC besides the mDNS AP configuration. For mDNS AP, no sync up is needed on standby as the AP configuration information is always stored on AP.
Show Commands on WLC
■WLC > show mdns profile summary
■WLC > show mdns profile detail <profile-name>
■WLC > show mdns service summary
■WLC > show mdns service detail <service-name>
■WLC > s how mdns domain-name-ip summary
■WLC > Show interface detail <interface-name>
■WLC > Show interface group detail <interface-group-name>
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)