controlling the frequency and volume of hub list sharing
Article ID: 416305
Updated On:
Products
Issue/Introduction
The DX UIM hub shares its list of known hubs with other known hubs, so that eventually every hub in the network will know about every other hub.
In a large environment this has been observed to use a significant amount of network bandwidth. Is there anything that can be done to reduce the frequency at which hub lists are propagated to other hubs?
Environment
DX UIM - 20.4, 23.4
hub - 9.40 or higher
Cause
Large number of hubs; reduce unnecessarily frequent sharing of hub information; limited bandwidth
Resolution
In order to understand the manner in which hub information is shared among hubs, it is first important to understand how UIM treats the concept of proximity.
Proximity, in simple terms, is a measure of the number of "intermediate" hubs that traffic passes through from one hub to another.
Two hubs which are in the same local LAN/same subnet and are directly able to communicate on port 48002 (e.g. via a Name Services entry or broadcast discovery) will see each other as having a proximity of zero; this means that for "Hub A" to talk to "Hub B", the number of intermediate hubs or "middlemen" is zero.
Similarly, two hubs which are directly connected via an SSL tunnel (tunnel server and tunnel client) will see each other as proximity zero; the client talks directly to the server with no middleman hub.
When hubs share their hub lists, they share them with hubs that have a proximity of zero. Each hub in turn shares its list of known hubs with other hubs that are "proximity zero"; in this way the hub lists are propagated to each other and eventually all the hubs will know about all the other hubs.
There are two confguration keys that are directly relevant to the frequency of hublist sharing. When not present in hub.cfg, each has an internal default value of 600 seconds (10 minutes).
hublist_check_delay: at this interval, the hub sends a list of "changed" hubs to its other (proximity 0) hubs. This means any hub that is down, been upgraded, or has undergone any other "change" in its status.
hubs_update_interval: at this interval, the hub sends the full hublist of all its known hubs to all its proximity 0 hubs, regardless of whether they have changed or not.
There are additional keys that come into play as well and should be adjusted if the first two (especially hubs_update_interval) are adjusted:
hublist_check_inactive_delay: this defaults to a value of 900 (15 minutes) and defines how often we check the hub lists to see if any of them have been inactive longer than expected (based on hubs_update_interval).
hublist_temp_timeout: this defaults to 1800 (30 minutes) and defines how long a hub must be inactive before we remove it entirely from the hub list.
-----
So in other words, this could be described as: every 15 minutes, the hub checks to see if, within the last 15 minutes, any hub has been inactive for 10 minutes.
It is actually slightly more complicated because there is a 2-minute offset to allow for latency or race conditions, so it could be more accurately described as:
Every 15 minutes, the hub checks to see if, within the last 15 minutes, any hub has been inactive for 10 minutes.
If we describe this in terms of how the intervals work:
Every (hublist_inactive_check_delay) seconds, the hub checks to see if any hub has been inactive for (hubs_update_interval + 120) seconds. If so, it logs a message that the hub has been inactive for (hubs_update_interval) seconds.
This means that essentially if two check intervals go by and the hub is marked inactive by the end of both of them, then the inactive hub will be removed from the hublist.
So all of these should be tied together:
hubs_update_interval should be set to how often the hubs are expected to update their lists; hublist_check_delay should be set to this same value.
hublist_check_inactive_delay should be set to 1.5x that number;
hublist_temp_timeout should be set to 2x hublist_check_inactive_delay
So for example if you want to reduce the frequency at which updates are shared:
hublist_check_delay and hubs_update_interval can be set to 3600 (once per hour);
hublist_check_inactive_delay should be set to 5400; (if hubs are inactive for 1.5 hours, mark them so)
hublist_temp_timeout should be set to 10800; (if hubs are inactive for 3 hours, delete them from the list)
Note that this will have an important side effect which is to make the system less responsive to changes at the hubs.
if a hub is a tunnel client and is moved to a different tunnel server, or a hub is renamed, or an old hub is decomissioned, it will take longer to reflect the changes. This is because the way these changes are propagated has to do with hublist_temp_timeout; a hub has to "expire" and be removed from this list before it can be re-added from another source, which will happen on the next hubs_update_interval cycle; so with the example settings above, it will take 4 hours for a renamed hub to reflect its new name in Infrastructure Manager whereas with the default settings it would take about an hour.
Broadcom does not recommend changing any of these settings without guidance from support, as the default values are well-tested and have been developed over many years to achieve a balance between responsiveness to changes and stability of the environment. Changes to these values may have unexpected consequences.
Additional Information
In DX UIM Secure Hub only (e.g. version 23.4.5S) in some circumstances, a tunnel server will aggressively issue "hubup" calls which trigger hublist sharing every 30 seconds; this will be resolved in hub 23.4.7 (ETA March/April 2026).
Feedback
