AirGroup

• 1: AirGroup
• 2: Architecture of the AirGroup technology
• 3: Configuration of AirGroup for an AOS 10 environment
• 4: Personal AirGroup
• 5: Survivability

1 - AirGroup

In today’s interconnected and mobile-centric world, seamless communication and interaction between devices are essential. HPE Aruba Networking’s AirGroup service emerges as a powerful solution designed to bridge the gap between diverse devices and the services they offer, enhancing the user experience within enterprise networks. At its core, it leverages zero-configuration networking to facilitate the discovery and utilization of multicast DNS (mDNS) and Simple Service Discovery Protocol (SSDP) services. These services encompass a wide range of functionalities, including Apple® AirPrint, AirPlay, Google Cast streaming, and Amazon Fire TV integration etc, all of which are integral to the modern digital workplace.

AirGroup simplifies the management of diverse devices, each with its own set of services, enabling users to seamlessly access these services from their mobile devices, laptops, and more, all within an enterprise network environment. Whether it’s sharing a presentation via AirPlay, streaming content through GoogleCast, or enjoying Amazon Fire TV services, AirGroup empowers users to be more productive and efficient.

This service is not limited to wireless connections; it seamlessly integrates wired and wireless devices, making it a comprehensive solution for modern network environments. Whether you’re in a bustling corporate office, a dynamic educational institution, or any enterprise setting, AirGroup enhances the functionality of your network by enabling devices to communicate effortlessly.

Key Features

• Service Discovery: Aruba AirGroup simplifies the process of discovering and accessing services and resources available on the network across layer 2 domains. It enables devices to automatically detect and connect to services such as printers, file servers, media devices, and other resources without the need for complex configurations.

• Device Isolation and Security: AirGroup ensures that devices can only discover and communicate with other devices within the same security and policy domain. This isolation prevents unauthorized access to sensitive information and enhances network security and privacy.

• User Role and VLAN Based Access Control: Administrators can implement user role and VLAN based access control policies using AirGroup. This allows them to define specific rules and permissions for different user groups in different VLANs, ensuring that users have appropriate access to services and resources based on their roles and VLANs.

• Enhanced User Experience: By streamlining service discovery and enabling seamless communication between devices, Aruba AirGroup improves the overall user experience. Users can effortlessly access shared resources and collaborate effectively, boosting productivity and satisfaction.

• Easy Configuration and Management: AirGroup is easy to configure and manage through Aruba Central management platform. Administrators can use a user-friendly interface to set up and monitor service discovery and communication settings efficiently.

2 - Architecture of the AirGroup technology

In transitioning to AOS 10, the AirGroup service has undergone a significant architectural overhaul to meet the dynamic needs of modern enterprise networks. In AOS 8, its centralized model struggled to cope with the growing number of mDNS/SSDP devices. Recognizing the need for change, Aruba reengineered AirGroup, shifting away from the single-central-system approach. In this new design, AirGroup server cache is distributed to every AP in the network. This shift empowers AirGroup to efficiently handle the increasing device population and their evolving behaviors while achieving exceptional performance and scalability.

In this revamped architecture, AirGroup operates as a distributed model, dividing functionality between APs and the AirGroup Service in Aruba Central. This innovative approach ensures AirGroup remains efficient and adaptable to meet the evolving demands of modern enterprise networks.

The new AOS 10 architecture

• Diverse Service Advertisement Frequencies - Various mDNS/SSDP devices relay service advertisement frames at intervals ranging from 5 seconds to 2 minutes or more. To ensure that a single or a subset of servers with aggressive advertisement tactics do not monopolize the system, the new AirGroup architecture can manage service advertisement frequency effectively.

• Variable Client Query Frequencies - Applications like YouTube and Netflix constantly scan for new servers through mDNS/SSDP query frames, especially during video streaming. As queries generally outnumber service advertisements (20% advertisements vs. 80% queries), prompt query response times are essential without causing delays in processing service advertisements.

• Proliferation of Unsupported Service Advertisements - The Bonjour protocol permits new applications to define and advertise services. As the usage of Wi-Fi BYOD devices continues to grow, the quantity of services being advertised and queried naturally fluctuates. Within this fresh design, each AP is equipped to intelligently filter and drop unsupported service advertisement and query packets originating from devices. This approach ensures that the responsiveness of AirGroup services remains undisturbed, even in the face of numerous unsupported services being advertised and queried by devices.

• Ease of Serviceability - The new AirGroup architecture prioritizes ease of service, this includes the configuration and the provision of MRT Dashboards, APIs, alerts, and visibility into the state of APs.

• Horizontally Scalable Architecture - Given the inherent nature of cloud-based deployments, the AirGroup service can be horizontally scalable by merely scaling up pods.

AirGroup operations in AOS 10

AirGroup on each AP in AOS 10 serves as a protocol-aware proxy cache for service discovery protocols such as mDNS and SSDP. It intercepts and decodes these protocol packets from the L2 header, storing essential information in a cache.

In the AirGroup architecture of AOS 10, two components collaborate to support mDNS/SSDP functionality:

• AirGroup Service in Aruba Central

• AP mDNS module in every AP

Devices capable of mDNS/SSDP periodically broadcast their capabilities in the network, referred to as AirGroup servers. Devices searching for these services or capabilities are known as AirGroup users, leading to two distinct packet flows within the AirGroup application:

• Query packet flow

• Advertisement packet flow

When an AP boots up, its mDNS process receives the AirGroup configuration, which originates from Aruba Central. This configuration encompasses AirGroup’s enable/disable status, service enable/disable status, disallow-role/vlan per service, and allowed role/vlan per service.

Each AP maintains two types of AirGroup server caches:

• Discover Cache: This cache stores AirGroup servers directly connected to the AP. It facilitates sending delta discover cache updates to AirGroup service in Central and ensures cache coherency during AP-Central connection downtime.

• Central Cache: The AirGroup service in Central processes cache updates from each AP, applies policies, and sends cache sync messages to the AP and its neighboring APs. The mDNS process on the AP uses these updates to construct the Central cache database. This cache contains only the synchronized cache from the AirGroup service. All AirGroup client queries are answered from this cache after applying configuration policies and per-server global policies.

The mDNS process in the AP primarily handles three processes:

• Advertisement process

• Query process

• Cache synchronization with AirGroup service in Central

Advertisement process

The Advertisement process manages new AirGroup server advertisements or updates (cache add/update), server disconnects (cache delete), and suppressed services dropping. Each AP’s mDNS process actively listens on a RAW socket, capturing mDNS/SSDP server advertisement packets. These packets undergo configured policies, including AirGroup service enabling/disabling, disallowed/allowed client roles, and disallowed/allowed VLANs. After policy assessment, the server entry is either updated or added to the AP Discover Cache table.

For new servers, all cache records from the packet are sent to the AirGroup Service in Central. For updates, only the delta updates are relayed. If advertised services are unsupported or disallowed in specific VLANs or client roles, the AP takes direct action by dropping the packet. Simultaneously, information about the suppressed service is forwarded to the AirGroup service in Central to maintain visibility.

The subsequent diagrams illustrate specific workflows for cache entry creation and updates, cache entry deletion, handling unsupported or disallowed service packets.

Query process

During the query process of APs, when a device seeks mDNS/SSDP services offered by another device, the mDNS process on the AP accesses its Central cache. This cache is built and continuously updated with AirGroup server/service records synchronized from the AirGroup service in Central.

For each incoming query, the mDNS process applies a set of policies, including service configurations (enabling/disabling), disallowed/allowed VLANs, and/or disallowed/allowed client roles. After this filtering process, the mDNS process consults the Central cache for records corresponding to the requested service IDs. If cached records are found, it assembles response packets with these records as the payload and subsequently dispatches them as unicast packets to the querying client.

In cases where all records cannot fit within a single packet, they are transmitted in successive packets. It’s important to note that there is a predefined hard limit, currently set at 150, for the maximum number of records that can be sent in response to any query. Future iterations may allow for configurability in this regard.

Cache synchronization

The AirGroup service in Central plays a pivotal role in cache synchronization:

• It processes the Discover cache updates received from each AP. Following the application of relevant policies, the AirGroup service dispatches cache synchronization messages to both the respective AP and all neighboring APs.

• The mDNS process on the APs then processes these cache synchronization updates to construct the Central Cache database. This database exclusively comprises cache entries that have been synchronized from the AirGroup service in Central. All client queries draw from this cache, with all configured policies and per-server global policies applied.

• In scenarios involving configuration changes or during roaming events, the AirGroup Service sends synchronization updates to all neighboring APs, ensuring the Central cache remains current and up to date.

To maintain cache coherency and consistency:

• Each AP calculates the crc64 checksum for all Service Identifier counter IDs in both the Discover and Central cache databases. This checksum, along with the Discover cache checksum and Central cache checksum, is included in the periodic checksum messages transmitted to the AirGroup service in Central.

• The checksum is routinely updated with each central cache synchronization message received, reinforcing the cache’s integrity. This process is especially valuable in scenarios involving connectivity disruptions and aids in recovering from cache losses during connection down/up events.

Ultimately, this design approach solidifies the Central Cache as the definitive and authoritative source of information, ensuring a robust and reliable service discovery environment.

3 - Configuration of AirGroup for an AOS 10 environment

AirGroup configuration policies are a pivotal component in managing and controlling service discovery within the network. These policies provide administrators with the flexibility to define how AirGroup functions and ensure that it aligns with the specific requirements and security standards of the organization.

Here are some key aspects of AirGroup configuration policies:

Enabling AirGroup services

AirGroup services can be managed at both Central Global level and the AP group level. When configuring at the group level, it takes precedence over the settings at the Global level.

Administrators have the flexibility to selectively enable or disable specific services. This capability empowers organizations to customize their network environment, accommodating essential services while effectively managing and mitigating potential security risks or unnecessary services.

For instance, suppose you have 7 predefined AirGroup services enabled globally. However, in a specific AP group, you only wish to enable AirPrint, AirPlay, and GoogleCast while disabling the other four services. In this scenario, you can accomplish this by disabling the remaining four services at the AP group level, allowing for precise control over service availability within that specific group.

The following two screen captures demonstrate how to enable the AirGroup service at the Global level and how to subsequently disable the DLNA media service at the AP group level, effectively superseding the Global level configuration.

User role and VLAN-based policies

AirGroup configuration policies offer granular control by allowing the application of policies based on user roles and VLAN assignments. This precise control mechanism ensures that specific services are exclusively accessible to authorized users or devices within designated network segments. This approach not only bolsters network security but also facilitates the isolation of services as necessary. Both role and VLAN-based policies provide the option to either “allow service” or “deny service,” granting administrators flexibility in defining access rules.

Wired and wireless servers

In a wireless network, a wireless AirGroup server is automatically placed by the AP it connects to, becoming visible and accessible to clients within one hop RF neighborhood of the server’s AP, provided the AirGroup policies allow it.

However, for wired AirGroup servers, automatic positioning in relation to AP locations does not occur. To enable wired AirGroup servers to be shared with wireless clients in AOS 10, global server policies must be configured.

Within a server policy, specific to a server’s MAC address, administrators can stipulate which user roles are permitted or prohibited. Additionally, administrators need to define a list of APs to which the wired AirGroup server will be visible. As a result, all clients connected to those APs will gain visibility and access to the server. This configuration ensures seamless accessibility to wired AirGroup servers for wireless clients within the network. In current release, maximum 50 APs are allowed to be in the visibility list.

Global server policies also serve another crucial purpose – ensuring the visibility of wireless AirGroup servers when a specific server is located beyond the one-hop RF neighborhood. This situation may arise when there’s a need to allow wireless clients to access a server that is not within the typical range of nearby APs the wireless clients connect to.

For instance, consider a library where there’s only one AirPlay printer available, but some APs are situated beyond the one-hop RF neighborhood of the printer. Consequently, clients connected to these remote APs cannot access the printer. In such scenarios, the solution is to establish a server policy for the printer at the Global level and include all relevant APs in the visibility list within the server policy.

By doing so, the configuration ensures that clients connected to any AP in the list, whether within the immediate RF neighborhood or beyond, can seamlessly access the printer. This flexibility in defining server visibility allows organizations to meet their specific connectivity requirements and provide a consistent user experience.

Leader AP for each wired AirGroup server

In AOS 10, the concept of a Leader AP is crucial for managing wired AirGroup servers. For a wired AirGroup server to be recognized and learned by the APs, the VLANs of the wired servers must be trunked to the switch ports connected to the APs. This ensures that all APs on the same VLAN can detect these wired servers. To avoid the inefficiency of having every AP on the same VLAN send redundant server updates to Central—which would generate excessive duplicate information and waste AP resources and WAN link bandwidth—AOS 10 introduces the Leader AP role for each wired AirGroup server on the same VLAN. Central selects a Leader AP, and only this Leader AP is responsible for sending any further updates about the server after it has been learned.

Each wired AirGroup server has its own Leader AP, and any AP can act as the Leader AP for up to 10 wired servers within the same VLAN. This distributes the Leader AP responsibilities and load across the APs on the VLAN. As we know, every AP maintains two cache tables for AirGroup servers: the Discover Cache, which stores all directly connected wireless servers, and the Central Cache, which contains server entries distributed by Central, these entries are used by the AP to service MDNS/SSDP queries. The Leader AP for a wired AirGroup server will cache this specific wired server in its Discover Cache table and send updates for this server to Central. Central then distributes the server information to other APs in the RF neighborhood.

Wired AirGroup server migration considerations from AOS 8 to AOS 10

In AOS 10, AirGroup operates solely on each AP and not on the gateways. To ensure that all wired AirGroup servers are recognized, the VLANs associated with these servers must be trunked to the switch ports connected to the APs. Therefore, when migrating from an AOS 8 AirGroup network, which is based on Mobility Conductor and Mobility Controller, to AOS 10, it is necessary to remove the wired AirGroup server VLANs from the switch ports connected to the gateways and add them to the switch ports connected to the APs. This allows the MDNS/SSDP packets from the wired servers to be detected by the APs, enabling them to learn these servers and make them visible to clients connected to neighboring APs.

Predefined services

With an AP foundation license, 7 predefined services are available, including AirPlay, AirPrint, Googlecast, Amazon_TV, DIAL, DLNA Print, and DLNA Media. For these 7 predefined services, administrators have the option to disable or suppress specific service IDs that may pose a security risk. This proactive measure prevents these potentially risky services from being discovered or accessed within the network, bolstering security and reducing the attack surface.

Custom services

HPE Aruba Networking AirGroup encompasses 7 predefined services, including AirPlay, AirPrint, Googlecast, Amazon TV, DIAL, DLNA media and DLNA print. However, the custom service feature extends the flexibility of AirGroup by enabling customers to configure additional AirGroup services beyond the 7 predefined ones. This empowers organizations to tailor their service discovery environment to suit their specific needs and applications.

With custom service policies, customers can define and manage unique AirGroup services that are not part of the standard predefined set. This customization allows organizations to integrate specialized services, applications, or devices into their network while still benefiting from AirGroup’s service discovery and access control capabilities.

For example, a company may have proprietary in-house applications or devices that need to be discoverable and accessible by authorized users within their network. By utilizing the custom service feature, administrators can set up policies that govern the visibility and accessibility of these custom services based on user roles, VLAN assignments while maintaining the security and control provided by AirGroup.

In essence, custom service policies within AirGroup empower organizations to expand and adapt their service discovery ecosystem beyond the predefined services, enhancing the network’s versatility and accommodating their specific requirements.

Custom services can exclusively be configured at the Global level as the following screen capture, which illustrates the manual addition of a custom service. Typically, a single AirGroup service may encompass multiple service IDs, and manually configuring these IDs can be a laborious and error-prone process. To streamline this procedure, the “List” window in the AirGroup section at the Global level offers a comprehensive list of over 140 suppressed services, covering nearly all mDNS/SSDP services available in the market.

Users can conveniently search for and highlight the specific service they wish to add. As a result, the service IDs associated with the selected service are automatically incorporated. When creating a custom service, users need only provide the service name and con user role/VLAN policies. The following screen capture serves as an illustrative example of how to add a custom service via the Suppress Service list within the “List” window. This feature simplifies the process and enhances the accuracy of custom service configuration within AirGroup.

Licensing requirements

Access points have two options for licensing in Central: the AP Foundation license and the AP Advanced license.

In earlier versions of Central, the AP Foundation license only allowed the use of the seven predefined AirGroup services: AirPlay, AirPrint, Google Cast, Amazon TV, DIAL, DLNA Print, and DLNA Media. When originally deployed, the AP Advanced license was required for custom services but this is no longer the case. Now, the AP Foundation license supports both the seven predefined AirGroup services and custom services.

Monitoring

AirGroup offers comprehensive monitoring capabilities, enabling administrators to track various aspects of service discovery. This includes monitoring server availability for specific user roles or VLANs, as well as monitoring server and service entries, which provide information about associated VLANs, user roles, and usernames, among other details.

4 - Personal AirGroup

HPE Aruba Networking Personal AirGroup feature, once activated in Central, leverages the capabilities of HPE Aruba Networking’s network infrastructure. This allows clients to share various wireless devices, including printers, smart TVs, IoT devices, and more. The streamlined sharing process enhances the client experience, simplifying wireless device discovery and access without the need for intricate setups or additional software. Clients can initiate sharing through the Cloud Guest Portal, adding further convenience to the process.

Personal devices are exclusively shared with wireless clients authenticated through the UPN (User Principal Name) format. In the current phase, only MPSK AES SSID device owners can share their devices, and the CloudAuth server serves as the supported authentication server for the MPSK SSID. Sharing a wireless personal device is possible with either MPSK AES or 802.1X authenticated clients, facilitated through the “Manage my devices” portal link hosted by Cloud Guest at the MPSK Wi-Fi password portal. However, this is contingent upon the availability of wireless sharing clients’ user entries in the identity repository utilized by Cloud Auth. For example, if an 802.1X client is authenticated by another RADIUS server, such as HPE Aruba Networking ClearPass, and the same client’s user entry is available in the identity repository used by the Cloud Auth server, then the wireless personal device owner can share with this client.

This feature introduces the concept of “Personal Servers or Devices” and “Public Servers or Devices”:

• Personal Servers or Devices: Wireless devices associated with a username are default “Personal Devices” with the option to manually change the classification to public when Personal AirGroup feature is enabled.

• Public Servers or Devices: Devices without a username or associated with a username in the public server list are automatically classified as “Public Devices” when Personal AirGroup feature is enabled at the Global level. When Personal AirGroup feature is disabled, all AirGroup servers are considered as public servers.

Here’s how Personal AirGroup typically work in AirGroup:

• Device Discovery and Announcement: Device Discovery and Announcement: AirGroup-enabled wireless devices use mDNS or SSDP to announce their presence on the network, providing information about the device and the services it offers.

• User Identification and Access Control: AirGroup distinguishes wireless personal devices owned by individual users using the UPN format username. Personal devices are automatically accessible by the device owner with the same username or through sharing client lists configured in the Cloud Guest portal.

• User-Centric Experience: With Personal AirGroup, wireless users can easily locate and interact with their own or other clients’ devices, as well as discover shared devices within their authorized scope. This simplifies tasks like printing, streaming, or accessing resources without the need to configure device-specific settings.

• Security and Privacy: AirGroup ensures secure device sharing and respects user privacy. Administrators can define granular service policies, preventing unauthorized access. User authentication ensures that only sharing clients can share and access their devices.

• Cross-VLAN Sharing: In segmented VLAN environments, AirGroup facilitates device sharing across different VLANs. This feature is useful when users in different departments or areas need to share resources while maintaining network segregation.

• User Control and Management: Administrators can centrally manage sharing policies, configuring rules, permissions, and visibility settings based on organizational requirements using user roles, VLANs, and service IDs.

Personal AirGroup contributes to a collaborative and efficient networking environment, empowering users to interact with both their personal devices and shared resources within the organization.

Workflow

The process of sharing personal devices is compatible with MPSK servers and MPSK/dot1x clients which are authenticated via CloudAuth in Central. Here’s a breakdown of the workflow:

• The AirGroup server undergoes MPSK authentication with the CloudAuth server in steps 1 to 4. The server’s username is transmitted to the AP through the username Vendor-Specific Attribute (VSA) at step 3.

• Subsequently, the AP establishes a Discover cache entry for the AirGroup server at step 6, connected directly to the AP after receiving MDNS advertisement packets at step 5. The Discover cache update is then forwarded to Central at step 7.

• If the Personal AirGroup feature is active and the server’s email address is not in the list of public server usernames, the AirGroup service in Central fetches the sharing policy for this specific server from the server sharing policy database at step 8.

• Any device owner can share their AirGroup server via the “Manage my devices” portal hosted by Cloud Guest. The portal page link is conveniently available at the bottom of the MPSK Wifi password portal page, and access instructions are detailed in the following accompanying screen captures.

• At step 9, a Central cache entry is generated for this server, contingent upon its compliance with the AirGroup policy.

• The Central cache updates are disseminated to neighboring APs, specifically those within a one-hop distance from the AP to which the AirGroup server is connected.

• Consequently, all Access Points within the RF neighborhood establish a Central cache for this specific server. This cache becomes instrumental in handling future mDNS queries.

It’s crucial to note that the sharing radius of the AirGroup server’s visibility is confined to a one-hop RF neighborhood. Effective interaction between the client and the AirGroup server is only achievable when both are within the proximity of a single-hop RF neighborhood.

Configuration

• Enable Personal AirGroup at Global level.

• Get into MPSK management window at the section of Security -> Authentication & Policy at Global level.

• Copy the MPSK password portal page URL and distribute it to the personal device owners.

• The personal device owners log into the MPSK password portal and clicks “Manage my devices” button, which directs them to Personal AirGroup portal page hosted by Cloud Guest.

• Within Personal AirGroup configuration portal, AirGroup server owners can share their devices with other clients or remove sharing access, allowing each device to be shared with a maximum of 8 clients.

Converting personal wireless AirGroup servers into public servers

When a wireless AirGroup server is associated with an AP and authenticated with a username, its initial device visibility type is always set to “Personal.” This is illustrated in the example of the server logged in as conf-room1@abc.com in the following screen capture. However, if there is a requirement to make this wireless AirGroup server become a public server and accessible to the broader RF neighborhood , you can follow these steps:

• In the list window of AirGroup servers at the Global level, locate the server entry that you want to share.

• Highlight the specific server entry.

• Click the “+” sign.

• This action will add the server’s username to the list of public server usernames as the example in the following screen capture.

• As a result, the server’s visibility status will change from “Personal” to “Public.” It will now be visible to clients within the same RF neighborhood instead of only being visible to the same user.

By following these steps, you can effectively convert a wireless personal AirGroup server into a public server, expanding its accessibility to clients in the RF neighborhood.

5 - Survivability

Survivability in Aruba AirGroup is a crucial aspect that ensures uninterrupted service discovery even when APs lose their connection to Aruba Central, the centralized management platform. This feature is vital for maintaining the functionality and accessibility of AirGroup services in scenarios where network connectivity to the central management platform is disrupted. Here’s an overview of how survivability is managed in Aruba AirGroup:

• Local Central Cache: APs in an Aruba AirGroup deployment maintain a local Central cache of service discovery information. This cache includes essential data about AirGroup services, servers, and associated policies. In the event of a network interruption to Aruba Central, this local Central cache allows APs to continue serving AirGroup services based on the last synchronized information.

• Service Continuity: The local Central cache enables APs to continue responding to service discovery requests from clients, even when they are unable to communicate with Aruba Central. This ensures that AirGroup services remain accessible to users within the AP’s coverage area, minimizing disruptions.

• Cache Synchronization: When the network connection to Aruba Central is restored, APs sends Discover cache updates and synchronize their Central cache with the latest information from AirGroup service in Central. This process helps maintain consistency across the network and updates any changes or policies made during the network outage.

• Delta Updates: Aruba AirGroup employs delta update mechanisms to transmit only the changes or updates to the local Central cache, rather than sending the entire cache. This efficient data transfer minimizes bandwidth usage during cache synchronization.

• Network Resilience: To further enhance survivability, organizations may implement network redundancy and failover mechanisms to reduce the risk of network outages affecting AirGroup operations.

In summary, Aruba AirGroup’s survivability mechanisms ensure that service discovery operations continue seamlessly even in the absence of a connection to Aruba Central. By maintaining a local Central cache and employing efficient synchronization methods, AirGroup enables uninterrupted access to essential services for users, enhancing the reliability and resilience of the network. These features are critical for organizations that prioritize service availability and seamless user experiences.