Client Management: Understanding the various mechanisms clients can use to automatically select their relay

Version 1
    Share This:

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    PRODUCT:

    BMC Client Management


    COMPONENT:

    Client Management


    APPLIES TO:

    Any version of BMC Client Management (BCM)



    DETAILS:

     

    1- Where is this configured on my agents?

    Select a device in the "Search" node or in the "Device Topology" node or in the "Device Groups" node then click on "Agent Configuration" and then on "Communication":

      

    User-added image

      

    There are two different ways of selecting a relay: 

      


    A- Static Relay:

    In this setup, clients will always use the same relay, no other relay is set. This is typically used for smaller LAN environments that do not have many clients. The problem with this configuration is that if your relay gets down, the clients will not be able to receive any operational rule, package etc until the relay is back up.
    This configuration should only be used on relays because they usually are direct children of the master as you do not want a master to be dynamically selected by relays.

    Note that if the relay is down it might still be possible to take control of its children, as long as they haven't changed their ip address, as they could be reachable through the ip that is known in the master database for them. Another solution to be able to take control of them until the relay is back in the Remote Control On Request. More information in the official documentation here (12.9).

      

    To configure it:
    - select on "Static Relay"

    User-added image

    - set the following:
    - "Parent Name": the relay hostname or its ip address (manually or by clicking on the icon)
    - "Parent Port:" the relay agent port (1610 by default)
     

      

    B- Auto-select Relay:

    Clients will attempt to find a relay using one or more of the selected methods in the order defined below: if a method cannot find the relay, it will return and the next method in the list will be tried:

    User-added image

    In this example the agent will test the"Relay List Server" mechanism first. If it fails to select a relay with this first mechanism it will try the next one: "DHCP Extended Option" mechanism then it'll try the "Backup Relay" mechanism if the second mechanism failed too. The mechanism selection order can be changed by clicking on the arrows right bellow "Selected Methods" (see the blue arrow on the next screenshot).

    How to add a new mechanism to the list:
    - select the mechanism on the right
    - click on the "+" button in the middle
    - configure the mechanism, e.g for the static relay:

      

    User-added image

      

     

      

    2- Configuring auto-selection:

    A- Relay List Server:

      

    The relay list mechanism allows devices to auto select relays as per their subnet. A list of subnets is set on a relay list server and when the device that is configured to connect to this relay list server contacts it, the server check its subnet, check if it exists and if it does it assign the relay configured for this subnet to the device. 

    This is the bet mechanism available for clients to auto-select their relays. Starting from 12.7 it is possible to easily set different relay list servers with the same or different lists of relays, it is now easy to set-up, chain relays in the list of relays available for one subnet etc.

    More information on this mechanism in this Knowledge Article (KA): Client Management: How to use the relay list mechanism to select relays

      


    B- DHCP Extended Option:

      

    This option will allow device to get their relay from an extended option set on the DHCP server scope options

    It's one of the best options to choose from as:
    - it can easily be set and updated if the server's hostname changes
    - it is possible to combine it with a DNS alias: the option 222 could be the same on all the dhcp servers and in the agent configuration but the local DNS alias would point to the relevant relay on the subnet
    More information on this mechanism in this KA: Client Management: How to use the dhcp mechanism to select relays

    Disadvantage:
    This mechanism as a downside: Client Management: When the dhcp mechanism is tried then failed, it takes 15 minutes to try the next mechanism.

      


    C- Backup Relay:

      

    This method is usually the last one in the list of the Select Methods, this would be the equivalent of the "last chance static relay", as it would be used if the previous mechanisms failed. This can be a list of servers, or one server only.
    The Backup Relay mechanism is also well suited for agents that connect through the internet sometimes and do not have access to a DHCP or to any relay list server. In this case, one or more internet facing relays can be added to the backup relays.

    Warning: The master should never be set as a backup relay, because it might hammer it if a relay with a lot of clients (or even worse, several relays) become unavailable, as then all the clients would (try to) become a child of the master. One or more dedicated backup relays should be set instead.

      

    Disadvantages:
    - priorities cannot be set if several relays are set into the backup mechanism, the server that will answer the fastest will be selected. Normally the closest relay to the device would be selected as it would most likely be reachable faster than the others, so it might not be a real disadvantage.
    - multiple rollout configurations could have to be created if you want it has to set a backup relay specific to where the device is in the world as an example. Another scenario is possible though: the same rollout is used for any device, but then several dynamic device groups would contain devices based on their geo, as an example, and these device groups would be assigned to different operational rules that would reconfigure the backup relay settings for the device to the most adapted backup relay in this geo.

      


    D- Static Relay:

      

    This option can also be set as an auto-selection mechanism. It can typically be used in an environment where there are few clients and relay or so and where the master will be the backup relay. The fourth screenshot from the top in this KA shows details on this mechanism.

      


    E- Auto-Discovery:

      

    This mechanism is pretty much deprecated since the Relay List and the dhcp mechanisms have been introduced. Auto-discovery lets client agents perform a network scan on either a pre-defined range of IP addresses or a number of neighbors surrounding their IP address.
    This has to be used cautiously as it creates network traffic and requires good configuration so agents efficiently find their relays.

      

    Prerequisite: the module "auto-discovery" must be loaded: if "Auto-Discovery" doesn't appear in the sub-node "Module Configuration" then select the tab "Configuration" and right click on the window, select "Load Modules" and select "Auto-Discovery":

      

    User-added image

      

    BCM usually recommends to set a list of relays instead of setting ip ranges if the user doesn't need the auto-discovery module for something else in BCM.

      

    Read the documentation for more information.

      


    F- Custom Script:

    This mechanism is pretty much deprecated since the Relay List and the dhcp mechanisms have been introduced. The Custom Script mechanism is used when none of the built-in methods mentioned above fits the environment and a customized script is available to handle relay discovery.

    The following will also apply to the scripts that can set on the "Backup Relay" mechanism.

    The script will be written in chilli. Information about Chilli can be found in the BMC Client Management - Chilli reference (this link goes to the 12.9 documentation,but the documentation hasn't been updated since 2014)

      

    For this to work, the custom script has to be deployed by packages to the devices and/or be added to the rollouts configurations post-install files:

    User-added image

      

    Advantage:
    It might be interesting to use the custom script to select a backup relay regarding of the device's location instead of selecting any relay from the "Backup Relay" list. This also allows the usage of a universal rollout instead of setting one up for every backup relay in this case.

      

    Some scripts examples can be found in the KA Client Management: Chilli scripts examples to select relays. Note that these are considered as customization and can't therefore be supported, it's only shared for education purposes.


    3- How to deploy a (new) config for the relay module:

    Follow this KA to learn how to deploy the new configuration to select relays: Client Management: How to deploy a new configuration to your Windows devices' relay module?.


    4- Troubleshooting

    In case some devices do not connect to their parent although they are reachable and that the service is started on the target, follow this KA: 
    - check the KA 000121351 which will help you understand why aren't your windows devices connecting to their relay

    Note:
    Do not hesitate to have a look at ideas on communities, there are several to request it to be easier to set/update the various relay settings.

     


    Article Number:

    000121366


    Article Type:

    Product/Service Description



      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles