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 updates from the central update server, peer devices get the updates from each other. This reduces bandwidth usage and speeds up update delivery, especially in geographically distributed networks.

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. IGEL Discovery uses a UDP-based mechanism to detect available update sources on the local network and provides an interface that update components use to determine update availability and select an appropriate update source automatically.

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.

Requirements

IGEL OS Version Requirements

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

Port Configuration Requirements

The Distributed Peer Update Server and the IGEL Discovery service need to run on different ports.

The ports need to be open and allowed by any type of firewall on the endpoint.

Configuring the Distributed Peer Update Server

You can configure an IGEL OS 12 device to serve as a Distributed Peer Update Server using a profile or local configuration:

1. Ensure that the device to be used as the Distributed Peer Update Server has a persistent IP address.

2. Go to System > Update > Distributed Peer Update Server.

3. Enable Enable Distributed Peer Update Server.

4. Set the server port.

5. Go to System > Update > IGEL Discovery.

6. Enable IGEL Discovery.

7. Set the port for the IGEL Discovery service.

8. If a profile is used, assign the profile.

9. Reboot the server.

Whenever a Distributed Peer Update Server has received an update, it needs to be rebooted before it can distribute the new update to other devices.

Configuring the Distributed Peer Update Clients

You can configure IGEL OS 12 devices to get their updates from Distributed Peer Update Servers using profile configuration:

1. In the profile, go to System > Update > IGEL Discovery.

2. Enable IGEL Discovery.

3. Set the port for the IGEL Discovery service.

4. Assign the profile to the IGEL OS 12 devices.

Should You Configure Client Peer Update Devices Also As Servers?

Since there is no downside to a peer acting as both a server and a client, you can simply enable both the IGEL Discovery service and the Distributed Peer Update Server on every device in the subnet.

This maximizes local availability of updates and reduces the likelihood that the application gets downloaded from the fallback download option.

How IGEL Discovery Works

The Distributed Peer Update mechanism is automated. Once IGEL Discovery is enabled and the Distributed Peer Update is configured on the IGEL OS 12 devices, the application distribution is automatic. Only one device initially downloads the application and then distributes it. No peer is overloaded, as each peer offers at most one download at a time, and it is not an issue if peers temporarily disappear and rejoin the network.

In detail, the mechanism works like this:

1. When a device needs an application update, IGEL Discovery sends a UDP broadcast within the local subnet to locate endpoints that can serve this request as Peer Update Servers.

2. IGEL Discovery listens for responses and evaluates replies as they arrive.
   The response for Peer Update Server availability can be ready or not ready, according to the following:

   • Default value is not ready at startup of the server and becomes ready after startup completes

   • Server switches to not ready when it stops, or when it starts serving a download

   • Server returns to ready after the last active download finishes or stops

3. In addition to overall server availability, IGEL Discovery also tracks whether the application is ready to be served. So IGEL Discovery will only report a Peer Update Server as ready to a requesting device if:

   • the Peer Update Server itself is ready, and

   • the requested application is available on the server.

4. The preferred candidate is the first server that indicates it is ready to deliver the requested application. If a server is not ready, IGEL Discovery will not provide a download URL.

5. If no other peer endpoint can serve as the Distributed Peer Update Server, the application gets downloaded from the fallback option.