Low Latency & Low Bandwith Network Zone

Wondering if anyone has ever come across this type of scenario and can offer some advice?

We have a network area that we want to add to our environment however there are a number of restrictions in this area and a number of requirements we need to meet before we can bring the servers into BigFix.

  • Area has extremely low latency
  • Area is charged for bandwidth
  • Agents should not connect (at any point) to the Root Server
  • Area will have a dedicated relay that only these agents should connect to

So I had a few options that I thought would work for this but need some confirmation that they would meet all the requirements first.

  1. Make the relay an Authenticated Relay and give only the agents that are in that area the key
    Q. Would this stop the agents communicating with the root server as required?

  2. Use AirGap
    I know that typically the root server also needs to be in the AirGap env however is it possible to set up a relay to act as the AirGap and leave the root server where it is?

  3. Block the agents at the Firewall level to ensure they can’t talk to the root server

I know there are a number of things we can do at the clinet / relay level to handle the low latency & low bandwith issues however I’m just not sure the best way to handle the rest.

Interesting case…I have a lot of thoughts on this but I’m going to need some time to find a free hour to write it up, probably later today. The first and second options aren’t going to accomplish what you need though so I wanted to save you some time going down those paths upfront.

1 Like

Does relay affiliation help you here?


The gist is that you can cause the relay(s) in that environment to only accept connections from clients with the correct affiliation setting.

If you go down the route of blocking at the firewall level, you will also need to give the clients failover relay settings (_BESClient_RelaySelect_FailoverRelay and/or _BESClient_RelaySelect_FailoverRelayList) so they can make first contact.

1 Like

All settings described at https://help.hcltechsw.com/bigfix/10.0/platform/Platform/Config/r_client_set.html

I think this breaks down into several categories

Keeping non-local traffic off the Relay

If you want the Relay to be autoselectable but only by the local clients, configure _BESRelay_Register_Affiliation_AdvertisementList with an advertisement that only the local clients seek via their _BESClient_Register_Affiliation_SeekList value. Do not include “*” in the Advertisement List, to prevent it from being an option for all automatic clients.

It takes more configuration, but you might also choose to make the relay only available via Manual Relay Select, in which case set _BESRelay_Selection_AutoSelectableRelay to 0, so clients will only choose that relay through manual selection.

Using Relay Authentication doesn’t help in this case, because the registration key is only used during initial registration; once a client, anywhere, has registered to the deployment and generated its client certificate, the client can use that certificate to freely roam afterward to an Authenticating Relay; it can authenticate with its client certificate then, and doesn’t need the shared secret.

There’s no Airgap capability that separates a Relay from the Root Server, or a Client from the Relay.

Keeping local traffic on the Relay

If using Automatic Relay Selection, set the local clients with _BESClient_Register_Affiliation_SeekList that only includes the local Relay. Do not include “*” so those clients will not roam to any other Relays outside of the defined seeklist.

If using Manual Relay Select, set the clients to use only the local relay.

On the clients, set _BESClient_RelaySelect_FailoverRelayList to include the local relay(s), so they will prefer to use the local Relay rather than failing-over to the Root Server if the local relay doesn’t respond to Ping or tcp connect. This can be set at installation time using a clientsettings.cfg so the client doesn’t try to reach the root server during initial registration.

If the local relay is down and cannot be reached, the client would eventually fallback to the masthead server name (or ‘last fallback relay’ defined in the masthead via BESAdmin). To completely prevent that, either block the access to the Root server via firewall, or add a HOSTS file entries on the clients to direct the masthead name back to the IP address of one of the local relays.

Minimizing the traffic on the local network

Once you have the right clients connected to the right relays, there’s more you can do to reduce the amount of traffic used by those clients.

Throttle the traffic used by the client or relay for posting upstream:

Throttle the bandwidth the relay allows the clients to use for downloads:
I’d generally avoid all the “Dynamic” throttles.

At the cost of the clients being less responsive to new content or actions, you could disable the Relay from notifying them about new content. The clients would only download new actions/fixlets when they poll for updates - either during the Relay Select interval or a Command Polling interval
_Enterprise Server_ClientRegister_DisableChildUDPMessages

(If you set those, you’d probable want to enable Command Polling as well)

You could also reduce the frequency at which these clients post new reports. For instance instead of updating ‘Last Report Time’ every minute, maybe increase it to ten minutes, or even an hour if you don’t need to see action results quickly:

You could also configure the clients to “go to sleep” for periods so they don’t Gather, Report, or run Actions for some time…see these settings and the various associated timer settings

1 Like