How to Configure Distributed Peer Update with IGEL OS 12 Devices

The Distributed Peer Update feature in IGEL OS 12 (formerly known as Buddy Update in IGEL OS 11) allows IGEL OS 12 devices to act as local update servers. Instead of each device downloading applications and firmware updates from a central repository (for example, UMS app proxy, Distributed App Repository, IGEL App Portal), devices in the same local network can share the download load between them.

Using the Distributed Peer Update mechanism reduces:

• bandwidth usage across WAN links

• load on central repositories

• time until all devices in a subnet receive the assigned updates

Starting from IGEL OS 12.7.4, the IGEL Discovery service allows endpoint devices on the same local network to automatically find and obtain updates from one another. For details, see the section How IGEL Discovery Works

Limitations and Known Issues

Community Applications Not Supported Yet

Currently, community applications are not supported by Distributed Peer Update. Including a community application in an update can break the entire update process. Fixes are planned to be added with a future IGEL OS 12 release.

HTTPS Not Supported Yet

Currently, the communication for the Distributed Peer Update is done through HTTP by default. HTTPS support is planned to be added with a future IGEL OS 12 release.

Components

Peer-to-peer distribution relies on two components that run on IGEL OS devices:

• IGEL Discovery

• Distributed Peer Update Server (“Buddy”)

Together, these components allow peer-to-peer distribution of applications and updates within the same subnet.

Requirements

IGEL OS Version

IGEL OS 12 devices need to run IGEL OS Base System version 12.7.4 or higher.

Port Requirements

The IGEL Discovery service and the Distributed Peer Update Server use separate ports, as described in the table below:

When configuring the ports, consider the following:

• The Distributed Peer Update Server and the IGEL Discovery service must run on different ports.

• The same Discovery port must be configured on all devices that should discover each other.

• The same Distributed Peer Update Server port must be configured on all devices that should act as peers for each other.

• The configured ports must be open and allowed by any host firewall on the endpoint and by any network firewalls between devices.

Network Requirements

Some network configurations may prevent discovery from working correctly. In these environments, devices may not be able to discover peers automatically.

For example:

• Wi-Fi networks with client isolation

• Networks that block broadcast traffic

Fallback Behavior with Repositories

Peer-to-peer distribution relies on IGEL Discovery to locate a device that already has the requested application. If no device in the subnet can provide the application, Discovery elects one device to download the application from a configured repository. This device becomes the fallback candidate. Once the application is downloaded and installed, the device can serve it to other devices as the Distributed Peer Update Server.

The fallback device downloads the application from the repository with the highest priority that contains the application. Supported repository types include:

• UMS App Proxy

• WebDAV repositories

• IGEL App Portal

• Other repositories configured under System > Update > Repositories

Can Fallback Be Disabled?

There is no direct setting to disable the fallback, because at least one device (the first device of the subnet) must obtain the application from a repository. However, repository usage is limited to the first download within a subnet.

Once a device has downloaded the application:

1. The device can serve the app to other peers if it is configured as Distributed Peer Update Server.

2. IGEL Discovery detects the available peer.

3. Other devices download the application directly from the peer instead of the repository.

Recommended Configuration - Intended Use Case

The intended use case is to operate Distributed Peer Update as a peer‑to‑peer network, where all devices both discover and serve updates.

To do this, you can configure devices through profiles:

1. Create a profile.

2. In the profile configurator, configure IGEL Discovery and Distributed Peer Update Server on all devices according to the table:

3. Save and assign the profile to the devices.

With this configuration:

• You can assign applications to devices without considering server roles.

• Discovery ensures that only one device at a time in a subnet uses the fallback to fetch the application from a repository.

• Once a device that is configured as a Distributed Peer Update Server has the application, it becomes a peer server for other devices.

• The distribution speed ramps up quickly due to exponential growth:

  • 1 Distributed Peer Update Server with the application → 1 device can download and become Peer Update Server

  • 2 Distributed Peer Update Servers → 2 devices can download and become Peer Update Server

  • 4 Distributed Peer Update Servers → 4 devices can download and become Peer Update Server

  • 8 Distributed Peer Update Servers … and so on …

Rollout Considerations for Large Environment

In very large environments or networks with limited bandwidth, application deployments can be performed in waves as a best practice.

Example rollout:

• First wave: 100 devices

• Second wave: next 100 devices

• Third wave: remaining devices

This prevents excessive simultaneous downloads and reduces network congestion.

How IGEL Discovery Works

Once IGEL Discovery and Distributed Peer Update are enabled, application distribution is automated.

Distribution Process

1. A management system (for example UMS) assigns an application to a device.

2. The device’s update daemon checks whether Discovery is enabled.

3. If Discovery is enabled, the update daemon asks Discovery to find a peer with the requested application.

4. IGEL Discovery broadcasts a UDP request within the subnet asking for the application.

5. Devices respond depending on their state.

Discovery Responses

Update Daemon Behavior

The update daemon reacts to Discovery responses as follows.

Update Progress Indicator Behavior

During peer discovery and fallback selection, the update progress indicator may temporarily remain at 0%.

This can occur while:

• Discovery searches for a peer server

• A fallback device downloads the application

• A peer disappears (for example powered off, network loss) and the update daemon has to request another server.

Once a peer becomes available, the download proceeds normally.

Proxy Considerations

IGEL Discovery and the update daemon behave differently when a proxy is configured.

This difference can lead to connectivity issues. For example:

1. Discovery identifies a peer that has the required application.

2. The update daemon attempts to download the application.

3. The request is routed through the configured proxy.

4. The proxy cannot route the request back to the local network.

Result: the peer update fails.

Workaround

To prevent peer-to-peer traffic from being routed through the proxy, add the local subnet(s) to the No Proxy for configuration:

1. Go to Network > Proxy > Manual proxy configuration.

2. Find the No Proxy for parameter.

3. Add the CIDR of the subnet, for example:

192.168.1.0/24
10.0.0.0/16

This ensures that peer-to-peer HTTP traffic is sent directly to local devices.

Alternative Configurations

Using Only a Subset of Devices as Peer Servers

You can configure a subset of devices as servers and the rest as clients.

Efficiency drawbacks of this configuration:

• The UMS assigns applications without considering which devices are servers.

• It is more likely that a client‑only device is elected first to use fallback.

• Due to the election protocol:

  • only one device at a time downloads from the fallback repository

  • if the elected device is client‑only, it cannot share the application with others

  • this significantly slows down distribution

To configure this model:

1. Create a profile for the servers.

2. Apply the following configurations:

3. Create a profile for the clients.

4. Apply the following configurations:

5. Save and assign the profiles to the selected devices.

Using Distributed Peer Update Servers Without Discovery

You can also disable Discovery entirely and configure Distributed Peer Update Servers as static repositories on the clients.

In this model:

• no auto‑discovery or election protocol is used

• no limitation of one client at a time coming from the election

• clients download applications directly from configured servers

This can be useful in tightly controlled environments where you want deterministic server selection and do not need the discovery behavior.

To configure this model:

1. Create a profile for the servers.

2. Apply the following configurations:

3. Create a profile for the clients.

4. Apply the following configurations and configure each Distributed Update Server as repository:

5. Save and assign the profiles to the selected devices.

Further Information

You might also find the following IGEL Community article useful: FAQ - Distributed Peer Update (Buddy Update).