The following document provides technical details on ICMP traffic generated by BES. If your BES deployment will have over 10,000 BES Clients or 50 BES Relays you should review this document prior to implementing the ICMP control settings or deploying BES. If you deployment has over 20,000 BES Clients or 200 BES Relays you should review this document with a support engineer from BigFix to determine appropriate values for your deployment.


ICMP is used in relay auto selections to automate and simplify the architecture of BES. A correctly configured BES Relay deployment with BES Clients close to BES Relays will create very low levels of network traffic and ICMP. The distributed architecture of BES allows for a high level of connectivity and real time responsiveness.


(Versions: 5.1, 6.0)


Contents:

  1. ICMP Traffic Technical Details
  2. ICMP Control Setting Recommendations
    1. _BESClient_RelaySelect_MaximumTTLToPing
    2. _BESClient_RelaySelect_ResistFailureIntervalSeconds
    3. _BESClient_RelaySelect_MinRetryIntervalSeconds
    4. _BESClient_RelaySelect_MaxRetryIntervalSeconds
    5. _BESClient_RelaySelect_IntervalSeconds

ICMP Traffic Technical Details TOP

The BES Client will generate ICMP traffic during the automatic and manual relay selection selection processes. Automatic relay selection is disabled by default but it is commonly enabled on all BES Clients.


In manual relay selection, the BES Client sends an ICMP packet at the Maximum TTL to BES Relays prior to attempting registration. If the ICMP does not reach a BES Relay the BES Client will not attempt to register with it. If the ICMP ping is successful and the BES Client registers with the BES Relay the hop count determined by the ICMP packet is reported in the Distance to BES Relay property.


During automatic relay selection, the BES Client sends out rounds of ICMP traffic with a constant TTL in each round. Each round of will send an ICMP packet to every BES Relay (BES Relays are listed in the ActionSite's Relay.dat file). Each round will each use a TTL at a higher value then the previous round, starting at 0 and skipping values at higher TTL values.


There are two main concerns with using ICMP in an enterprise network, the bandwidth consumed and overloading routers. Bandwidth is a major concern for deployments with large numbers of BES Clients because large numbers of BES Clients simultaneously running relay selection may cause network congestion. The main concern for routers is consuming too much CPU processing ICMP traffic. Routers will typically need to use more CPU processing a TTL of zero. Routers may be CPU constrained before a network link is bandwidth constrained.


A BES Server failure event can generate a higher then normal amount of ICMP traffic. If the BES Server is down, BES Client posts will begin to fill up in BES Relay FillDB folders and BES Clients will not be able to register with BES Relays. Once BES Relays have reached their FillDB buffer directory maximum capacity they will begin to reject BES Client posts. Finally, once BES Clients reach their Resist Failure Interval they will begin to run automatic relay selection. If the BES Server is down, automatic relay selection will fail until the BES Server is available again unless a failover BES Server is available.



ICMP Control Setting Recommendations TOP

_BESClient_RelaySelect_MaximumTTLToPing TOP

Default: 255 (Hops)


Details: This value represents the maximum TTL to use in automatic relay selection. This is a maximum value so a TTL of one less then this value will be used. For example, if this value is 10 then a TTL of 9 will be used but not a TTL 10. Also, the retrieved property "Distance to BES Relay" reports the number of network hops, which is one one less then the TTL as well. So, a BES Client that reports a distance of 3 would use a TTL of 4 during relay autoselection. Given both of these, a BES Client that reports a distance of 3 for the "Distance to BES Relay" property could have a MaxTTLToPing as low as 5 and still be able to autoselect to its current BES Relay.


Pros/Cons: A higher TTL value will allow the BES Client to find BES Relays that are farther away. At the default of 255 (or the maximum distance of an enterprise network) a BES Client would be able to reach any BES Relay in a BES deployment. A TTL at the distance between a BES Client and the BES Server would allow the BES Client to reach relays along the path to the BES Server from each BES Client if the BES Server is centrally located (but not past the BES Server). A higher TTL will generate more ICMP traffic during automatic relay selection because the BES Client will do one round of relay autoselection until the maximum TTL is reached. A smaller TTL will generate less ICMP but BES Clients will only be able to find BES Relays that are closer to it. BES Relays should be positioned close to their BES Clients and in most deployments will be within 5 hops from BES Clients.


Deployment Size: Over 50 BES Relays or over 10,000 BES Clients.


Recommended Value: 20

_BESClient_RelaySelect_ResistFailureIntervalSeconds TOP


Default: 600 (Seconds)


Details: This value represents the amount of time BES Clients will ignore communication errors before performing BES Relay selection. Once a BES Relay has been selected and the BES Client has successfully registered, it will ignore errors when it attempts to post its results to the BES Relay or BES Server for this long before deciding to choose another BES Relay. If the BES Server is down or the BES Relays are rejecting BES Client posts because their FillDB buffer directory is full.


Pros/Cons: A lower failure interval will allow BES Clients to quickly find alternative BES Relays in the event that a BES Relay is not available. This will give BES Clients a higher connectivity rate when BES Relays are uninstalled or having communication failures. If the BES Server is down and the BES Relay FillDB buffer directories are full, BES Clients will run autoselection after waiting this long. A higher value will allow more resilience for BES Server down time but slower failover rates for BES Relay down time or loss. Larger deployments should allow for more BES Server down time resilience to prevent excessive ICMP traffic during BES Server down time. Smaller deployments will benefit from a shorter resist failure value as long as ICMP caused by the BES Server being down is not problematic.


Deployment Size: Over 50 BES Relays or over 10,000 BES Clients.


Recommended Value: 3600 (1 Hour)

_BESClient_RelaySelect_MinRetryIntervalSeconds TOP


Default: 60 (Seconds)


Details: If the automatic relay selection fails (no BES Relays were found), the BES Client will try again after this many seconds. The BES Client will double this value on each successive retry that fails to locate a BES Relay. BES Clients will fail to find any BES Relay if the BES Server is down, the computer is disconnected from the network or a firewall is blocking ICMP.


Pros/Cons: A lower Minimum Retry Interval will allow the BES Client to run relay selection more often and find BES Relays faster once the failure is fixed. Running relay selection more frequently will generate more ICMP traffic but allow the BES Clients to recover from failures faster. A higher value will generate less ICMP but make failure recovery slower. For example, if a laptop momentarily loses its connection and can't find any BES Relays a lower retry interval will allow it to quickly find a BES Relay. On the other hand, if the BES Server is down causing BES Clients not to find any BES Client during automatic relay selection it would be best not to retry quickly and avoid generating ICMP during the down time.


Deployment Size: Over 50 BES Relays or over 10,000 BES Clients.


Recommended Value: 600 (10 Minutes)

_BESClient_RelaySelect_MaxRetryIntervalSeconds TOP


Default: 7200 (Seconds)


Details: After failing to find a BES Relay, the BES Client will continue to try to find a BES Relay. Each time it fails, the BES Client will double the time it spends until this maximum is exceeded. Then the BES Client will try with this maximum retry interval until it successfully selects a BES Relay. In the event the BES Client is waiting for a failure to be corrected this will be the maximum amount of time for the BES Clients to recover from the down period.


Pros/Cons: A lower Maximum Retry Interval will allow BES Clients to recover from down times faster while a higher value will force a longer recovery time. A lower value will cause more ICMP traffic since the BES Client runs relay selection more often.


Deployment Size: Over 50 BES Relays or over 10,000 BES Clients.


Recommended Value: 14400 (4 Hours)

_BESClient_RelaySelect_IntervalSeconds TOP


Default: 21600 (Seconds)


Details: The BES Relay selection algorithm will run this often. If a closer BES relay is found, the closer BES Relay will be used. Note that this interval is only used after a BES Client successfully registers with a BES Relay.


Pros/Cons: A smaller relay selection interval will allow BES Clients to find closer BES Relays more frequently whenever possible but create more ICMP during relay selection. For example, if a new BES Relay is created a lower relay select interval will allow BES Clients to use that BES Relay sooner through auto selection. Large deployments should increase this interval to reduce the total amount of ICMP and send manual relay selection actions if they need to force BES Clients to find closer BES Relays. Ie, if a new BES Relay is installed send a relay selection action to the BES Clients that you believe to be closest to this BES Relay.


Deployment Size: Over 50 BES Relays or over 10,000 BES Clients.


Recommended Value: 43200 (12 Hours)