(imported topic written by SystemAdmin)
i have more or less 60000 agent with 3700 relay in 6000 branchs
i have set affiliation group for auto selection , i have divided italy by region and i have affiliation group region by region.
i have set fileover relay for all client laptop and desktop
daily i have more or less 500 client in fileover , i have read some log file , the client if have problem to contact the last relay automaticaly go in fileover , the client don’t scan another relay
(imported comment written by SystemAdmin)
any idea?
(imported comment written by MattBoyd)
Have you taken a look at the
client relay configuration settings
?
Specifically, the settings that I would try experimenting with are:
_BESClient_RelaySelect_IntervalSeconds - setting this to a longer interval will make relay selection less frequent
_BESClient_RelaySelect_PingDelayMicroSeconds - This setting can be used to “slow down” the relay selection process
We do see this happen in our environment, particularly if a client has been in standby (sleep) for an extended period of time. It seems that the network connectivity is still flaky (link may be active but network traffic isn’t getting through) when the client wakes and attempts to perform relay selection, so it selects the failover relay. We have also deployed an action that forces the client to perform a relay select if it’s connected to the failover relay, and retry every 2 hours if a different relay is not selected. You can force relay selection with the action script command: relay select
(imported comment written by SystemAdmin)
my configuration is
“_BESClient_RelaySelect_IntervalSeconds”=“86400”
“_BESClient_RelaySelect_PingDelayMicroSeconds”=“1000000”
“_BESClient_RelaySelect_MaximumTTLToPing”=“25”
“_BESClient_RelaySelect_FailoverRelay”=“http://myServer.com:52311/bfmirror/downloads/”
“_BESClient_RelaySelect_ResistFailureIntervalSeconds”=“3600”
“_BESClient_RelaySelect_MinRetryIntervalSeconds”=“600”
“_BESClient_RelaySelect_MaxRetryIntervalSeconds”=“14400”
“_BESClient_Register_Affiliation_SeekList”=“myList”
i can test a task for force relay auto selection
but is strange ,
the normal operation if the first relay not accept connection ,the client search in list a new relay , but in the log file is not present this step
directly to fileover
(imported comment written by SystemAdmin)
I don’t know if this helps any:
Client version 8.2.1093 fixed an issue where relay selection could fail from ICMP loss on Windows 7 in rare situations, but introduced an auto relay selection problem on Macs. The next version is supposed to fix these issues.
Just wanted to clarify a doubt… Does the client use ICMP Echo Request & Reply to find the closest relay? Or does it use a heartbeat over TCP 52311 to try to find the closest relay?
We are facing an issue where 80% of devices(in a group) are able to identify the closest relay but 20% from that same group goes to Main Server directly and not even the TR.
Many people use the term ping in different sense; Specially when Relays are trying to tell the clients about new info… they use UDP Ping over 52311. So i wanted to clarify this.
Thanks.
The agent uses essentially an ICMP request. There is a heartbeat over TCP 52311 which is when it posts a report. The UDP is port 52311 also, but this is used from the BES server or relay to the client when an action is submitted.
So when setting up the firewall, TCP/UDP 52311 bi-directional and ICMP from the client to the relay/BES server. If you are ok with the client polling for the jobs then you could use that and the requirement for the UDP could be removed. http://www-01.ibm.com/support/docview.wss?uid=swg21505846
Is there a way to easily debug why few clients are not choosing the relays and going straight to main server? I verified the firewalls on these devices - same policies, same controls… yet few successfully get the local relay and few go to main only.
I have changed the relay selection interval to be lower(1 hr) to see what happens to these devices.
The Client’s debug log can be quite useful to diagnose Relay Selection:
http://www-01.ibm.com/support/docview.wss?uid=swg21505873#clientdebuglogging