Background

Each Adaptiva client is part of a peer-to-peer (P2P) network, and peers within the same physical network are designed to communicate directly with each other. On wired networks, this is often achieved using a combination of unicast and broadcast communication. However, broadcast traffic is generally disabled or restricted on Wi-Fi networks.

To ensure reliable operation over wireless, Adaptiva clients use unicast communication. Unicast is a method of sending a message directly from one device to another. In practice, this means that when a client needs to reach peers within its subnet, it sends a unicast message to each peer individually.

As part of the P2P network each subnet requires to have one Rendezvous Point (RVP). The RVP’s role is essential to coordinate messaging, content downloads, and other P2P functions.

This document provides a high-level overview of how that process works and explains potential impacts it may have at the network layer.

How Device Discovery Works During RVP Election

When a device becomes the RVP, it must identify and communicate with all peers in its subnet. To achieve this:

• The RVP maintains a list of active peers in the subnet. On startup of the client, RVP provides an initial list of all clients within the defined office.
• During normal operations the client, on startup, will be sent a list of RVPs from the server for the defined office.
• Whenever a peer client detects a new RVP, it sends a ‘hello’ message randomly within an interval of 0 to 8000 milliseconds. This helps in building the list dynamically on the RVP.
• When the Client sends a message to each peer:
  • The Windows operating system needs the MAC address associated with each IP address.
  • This is done using the Address Resolution Protocol (ARP).
• If a cached IP to MAC mapping is not found in the ARP Cache and ARP request is a broadcast, an ARP request is generated.
• Once resolved, the MAC address is then cached in the Windows ARP cache until the configured expiry duration.
• The client list on the RVP is used to simulate broadcasting and is achieved by unicasting the same message to each peer client.
• RVP maintains and uses additional ARP cache in case it needs to communicate to several peers in a short time, and this helps in avoiding generating lot of ARP requests.
  • This explains why you may observe a spike in ARP traffic when a new RVP is elected.

ARP Cache Behavior

The ARP cache/Neighbor Table is maintained by the Windows operating system and contains a device's IP address and MAC address. Below are some limitations of the ARP cache and some mitigations provided by Adaptiva:

• By default, The ARP table can hold up to 256 entries.
• If the subnet size exceeds this (e.g., larger than a /24 network), older entries may be dropped.
• Dropped entries require fresh ARP resolution when communication resumes, leading to new ARP requests.
• ARP entries also expire after a timeout period, which causes periodic refreshes.
  • This behavior is expected, but in large subnets it can result in more frequent ARP traffic.
• ARPs are not generated by an application, but by the OS network protocol stack. Because ARP traffic is aggregate, isolating a single application as the source is difficult. 

Mitigations and optimizations:

• Adaptiva added an internal ARP cache on the RVP that stores peer MAC addresses, which prevents packets from being sent to destinations not already present in the system ARP cache. 
• When a device joins a Wi-Fi subnet, it registers with the RVP, which caches its MAC address and minimizes repeated ARP lookups during peer-to-peer communication.

Potential Network Impact

There are several scenarios which can affect stability and performance of the network such as:

1. RVP Instability
   • If a client device does not receive the RVP announcement (due to packet loss, filtering or blocked ports etc.), it may assume no RVP exists and trigger a new election. 
   • However, new election is terminated by existing RVP as soon as an RVP announcement is received. 
2. Hardware Protections
   • Some network switches, routers, or firewalls implement rate-limiting or blocking when too many ARP requests are seen in a short period.
     • We strongly recommend you do not create subnets larger than what your network switch can handle. For instance, if a switch can only handle ~2000 APRs per second and you have a subnet with 4096 devices, this will increase the risk of rate-limiting and packet loss. 
   • In these environments, the RVP election process may lead to devices being temporarily blocked from communication and that will cause RVP instability as each RVP will be dropped from the network, and a new RVP election will occur.
3. Large Subnets
   • Subnets larger than /24 (256 addresses) increase the likelihood of neighbor table rollover and repeated ARP lookups.

Recommendations and Best Practices

To minimize ARP-related issues:

• Subnet sizing: Where possible, use /24 subnets for wireless networks.
• Wi-Fi Office Topology Sizing: If it is not possible to implement /24 subnets on the network layer it is advisable to split the Offices\Locations within the OneSite platform into multiple /24 ranges to reduce the overall potential impact on the network.
• Stable RVP election: Ensure all clients can communicate as required.
• Cache Size: Ensure the neighbor cache size is appropriate for the potential number of devices for the subnet.
• Network tuning: Ensure that ARP rate-limiting thresholds on switches and firewalls are compatible with expected RVP behavior.
• Cache awareness: Understand that ARP table timeouts are normal and periodic ARP refreshes should be expected.
• Wi-Fi Access Points: Ensure P2P Comms are allowed between Access Points (APs).
• Monitoring: Track ARP traffic patterns to identify abnormal bursts or repeated RVP elections.
• Intune: Intune relies entirely on the OS ARP cache, and can generate additional ARP traffic when peer-to-peer delivery is enabled in Intune. Allowing Adaptiva to handle the Intune traffic will reduce those ARPs. 

Summary

The ARP traffic generated during the RVP election process is a direct result of Windows resolving IP addresses for peer-to-peer communication. This is standard operating system behavior, not a malfunction. However, in large or highly segmented networks, ARP behavior can become more noticeable due to neighbor table limits, RVP Instability, or network hardware protections.

By understanding these mechanisms and planning network design accordingly, customers can minimize the impact and ensure stable operation of the Adaptiva client.

Links

Client Settings: Changing ARP Cache (Neighbor Cache) Settings – Adaptiva Support Portal

Adaptiva Client Settings

The Adaptiva client has the following two configurations that can be used to tweak performance if required.