Client Initiated Connection Flapping
32 views
Skip to first unread message
Brock Palen
Oct 3, 2019, 10:15:31 AM10/3/19
to bareos-users
I am running into issues where roaming clients using client initiated connections are un-reliable. They worked very well for a number of months but now I find that clients that we know are online, and the director reports as connected something as simple as
status client=<client>
Will just drop the connection, eventually the client comes back, but it causes a lot of backup failures and unreliable reporting.
All clients are windows 10.
Has anyone started seeing this? Should we try tuning some timeouts? Right now they are defaults.
The coming clients home connections (where we test) one is ATT DSL one is Charter Cable. Thanks
Brock Palen
1 (989) 277-6075
bro...@mlds-networks.com
www.mlds-networks.com
Websites, Linux, Hosting, Joomla, Consulting
status client=<client>
Will just drop the connection, eventually the client comes back, but it causes a lot of backup failures and unreliable reporting.
All clients are windows 10.
Has anyone started seeing this? Should we try tuning some timeouts? Right now they are defaults.
The coming clients home connections (where we test) one is ATT DSL one is Charter Cable. Thanks
Brock Palen
1 (989) 277-6075
bro...@mlds-networks.com
www.mlds-networks.com
Websites, Linux, Hosting, Joomla, Consulting
Jörg Steffens
Oct 4, 2019, 6:47:23 AM10/4/19
to bareos...@googlegroups.com
On 03.10.19 at 16:15 wrote Brock Palen:
the connection is lost after this, or will (2) the connection close
immediately?
> eventually the client comes back, but it causes a lot of backup failures and unreliable reporting.
>
> All clients are windows 10.
>
> Has anyone started seeing this? Should we try tuning some timeouts? Right now they are defaults.
On 1:
Well, it works a designed.
A connection is only used for one task/job.
On Client Initiated Connection the FD opens up a connection to the
Director. When the Director uses this connection, either by running a
job or running a status command, the FD opens up another connection, so
the Director has a spare one available.
The connection used by the Director will be closed after the task/job.
On 2:
Yes, you should set Heartbeat Interval like described in the documentation:
https://docs.bareos.org/TasksAndConcepts/NetworkSetup.html#client-initiated-connection
Regards,
Jörg
--
Jörg Steffens joerg.s...@bareos.com
Bareos GmbH & Co. KG Phone: +49 221 630693-91
http://www.bareos.com Fax: +49 221 630693-10
Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH
Geschäftsführer:
S. Dühr, M. Außendorf, Jörg Steffens, P. Storz
> I am running into issues where roaming clients using client initiated connections are un-reliable. They worked very well for a number of months but now I find that clients that we know are online, and the director reports as connected something as simple as
>
> status client=<client>
>
> Will just drop the connection,
So, will (1) the status command get executed, you receive an answer and
>
> status client=<client>
>
> Will just drop the connection,
the connection is lost after this, or will (2) the connection close
immediately?
> eventually the client comes back, but it causes a lot of backup failures and unreliable reporting.
>
> All clients are windows 10.
>
> Has anyone started seeing this? Should we try tuning some timeouts? Right now they are defaults.
Well, it works a designed.
A connection is only used for one task/job.
On Client Initiated Connection the FD opens up a connection to the
Director. When the Director uses this connection, either by running a
job or running a status command, the FD opens up another connection, so
the Director has a spare one available.
The connection used by the Director will be closed after the task/job.
On 2:
Yes, you should set Heartbeat Interval like described in the documentation:
https://docs.bareos.org/TasksAndConcepts/NetworkSetup.html#client-initiated-connection
Regards,
Jörg
--
Jörg Steffens joerg.s...@bareos.com
Bareos GmbH & Co. KG Phone: +49 221 630693-91
http://www.bareos.com Fax: +49 221 630693-10
Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH
Geschäftsführer:
S. Dühr, M. Außendorf, Jörg Steffens, P. Storz
Brock Palen
Oct 8, 2019, 12:03:37 PM10/8/19
to bareos-users
(sorry saw I wasn’t replying to the entire list)
Ok the problem remains,
A client that’s connected using client initiated connection is still dropping off when I try to query it
08-Oct-19 10:16 54 1 mills-feldman-fd
====
You have messages.
*status client=mills-feldman-fd
Connecting to Client mills-feldman-fd at <snip>
Handshake: Immediate TLS, Encryption: PSK-AES256-CBC-SHA
*
As you can see when I do status on it it just drops right away doesn’t hang, and doesn’t provide the usual expected feedback and now the client will be missing from the connection.
Should I try lowering the heartbeat?
Client {
Name = mills-feldman-fd
FDport = 9102
Address = <snip>
Catalog = myth_catalog
Password = “<snip>"
File Retention = 3 months
Job Retention = 6 months
AutoPrune = yes
Connection From Client To Director = yes
Connection From Director To Client = no
Heartbeat Interval = 60
}
> On Oct 5, 2019, at 12:07 PM, Brock Palen <bro...@mlds-networks.com> wrote:
>
> it prints:
>
> *status client=sch-hp-desktop-fd
> Connecting to Client sch-hp-desktop-fd at 192.168.67.99:9102
> Handshake: Immediate TLS, Encryption: PSK-AES256-CBC-SHA
>
> and then nothing, if I kill the console, the client is not listed in client initiated connections, but will eventually come back.
>
> I was just going to paste in the client config, but I noticed for both of them I had left the LanAddress populated
>
> Client {
> Name = sch-hp-desktop-fd
> FDport = 9102
> Address = <snip>
> LanAddress = 192.168.1.110
> Maximum Concurrent Jobs = 1
> Catalog = myth_catalog
> Password = “<snip>"
> File Retention = 3 months
> Job Retention = 6 months
> AutoPrune = yes
> Connection From Client To Director = yes
> Connection From Director To Client = no
> Heartbeat Interval = 60
> }
>
> Becuse doign a full over the network is bad so we have our own snowball running on a Raspbery Pi we mail to their house to do a full backup, then override the pool, mail it back, migrate job and then Always Incremental after that. So that is a difference from the two that work 100%.
>
> I removed that will see what happens.
>> You received this message because you are subscribed to the Google Groups "bareos-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to bareos-users...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/bareos-users/qn77vf%24871e%241%40blaine.gmane.org.
>
Ok the problem remains,
A client that’s connected using client initiated connection is still dropping off when I try to query it
08-Oct-19 10:16 54 1 mills-feldman-fd
====
You have messages.
*status client=mills-feldman-fd
Connecting to Client mills-feldman-fd at <snip>
Handshake: Immediate TLS, Encryption: PSK-AES256-CBC-SHA
*
As you can see when I do status on it it just drops right away doesn’t hang, and doesn’t provide the usual expected feedback and now the client will be missing from the connection.
Should I try lowering the heartbeat?
Client {
Name = mills-feldman-fd
FDport = 9102
Address = <snip>
Catalog = myth_catalog
Password = “<snip>"
File Retention = 3 months
Job Retention = 6 months
AutoPrune = yes
Connection From Client To Director = yes
Connection From Director To Client = no
Heartbeat Interval = 60
}
> On Oct 5, 2019, at 12:07 PM, Brock Palen <bro...@mlds-networks.com> wrote:
>
>
>> On Oct 4, 2019, at 6:47 AM, Jörg Steffens <joerg.s...@bareos.com> wrote:
>>
>> On 03.10.19 at 16:15 wrote Brock Palen:
>>> I am running into issues where roaming clients using client initiated connections are un-reliable. They worked very well for a number of months but now I find that clients that we know are online, and the director reports as connected something as simple as
>>>
>>> status client=<client>
>>>
>>> Will just drop the connection,
>>
>> So, will (1) the status command get executed, you receive an answer and
>> the connection is lost after this, or will (2) the connection close
>> immediately?
>
> Drops immediately,
>
>> On Oct 4, 2019, at 6:47 AM, Jörg Steffens <joerg.s...@bareos.com> wrote:
>>
>> On 03.10.19 at 16:15 wrote Brock Palen:
>>> I am running into issues where roaming clients using client initiated connections are un-reliable. They worked very well for a number of months but now I find that clients that we know are online, and the director reports as connected something as simple as
>>>
>>> status client=<client>
>>>
>>> Will just drop the connection,
>>
>> So, will (1) the status command get executed, you receive an answer and
>> the connection is lost after this, or will (2) the connection close
>> immediately?
>
>
> it prints:
>
> *status client=sch-hp-desktop-fd
> Connecting to Client sch-hp-desktop-fd at 192.168.67.99:9102
> Handshake: Immediate TLS, Encryption: PSK-AES256-CBC-SHA
>
> and then nothing, if I kill the console, the client is not listed in client initiated connections, but will eventually come back.
>
>>
>>> eventually the client comes back, but it causes a lot of backup failures and unreliable reporting.
>>>
>>> All clients are windows 10.
>>>
>>> Has anyone started seeing this? Should we try tuning some timeouts? Right now they are defaults.
>>
>> On 1:
>> Well, it works a designed.
>> A connection is only used for one task/job.
>
> Yep most the time it works.
>>
>>> eventually the client comes back, but it causes a lot of backup failures and unreliable reporting.
>>>
>>> All clients are windows 10.
>>>
>>> Has anyone started seeing this? Should we try tuning some timeouts? Right now they are defaults.
>>
>> On 1:
>> Well, it works a designed.
>> A connection is only used for one task/job.
>
>
>>
>> On Client Initiated Connection the FD opens up a connection to the
>> Director. When the Director uses this connection, either by running a
>> job or running a status command, the FD opens up another connection, so
>> the Director has a spare one available.
>> The connection used by the Director will be closed after the task/job.
>>
>> On 2:
>> Yes, you should set Heartbeat Interval like described in the documentation:
>>
>> https://docs.bareos.org/TasksAndConcepts/NetworkSetup.html#client-initiated-connection
>
> Yeah thought I did, and like I noted it worked very well for a long time, and now it’s spotty. One client is working much more than the other, and two others are 100% reliable but connect over a VPN rather than public WAN
>>
>> On Client Initiated Connection the FD opens up a connection to the
>> Director. When the Director uses this connection, either by running a
>> job or running a status command, the FD opens up another connection, so
>> the Director has a spare one available.
>> The connection used by the Director will be closed after the task/job.
>>
>> On 2:
>> Yes, you should set Heartbeat Interval like described in the documentation:
>>
>> https://docs.bareos.org/TasksAndConcepts/NetworkSetup.html#client-initiated-connection
>
>
> I was just going to paste in the client config, but I noticed for both of them I had left the LanAddress populated
>
> Client {
> Name = sch-hp-desktop-fd
> FDport = 9102
> Address = <snip>
> LanAddress = 192.168.1.110
> Maximum Concurrent Jobs = 1
> Catalog = myth_catalog
> Password = “<snip>"
> File Retention = 3 months
> Job Retention = 6 months
> AutoPrune = yes
> Connection From Client To Director = yes
> Connection From Director To Client = no
> Heartbeat Interval = 60
> }
>
> Becuse doign a full over the network is bad so we have our own snowball running on a Raspbery Pi we mail to their house to do a full backup, then override the pool, mail it back, migrate job and then Always Incremental after that. So that is a difference from the two that work 100%.
>
> I removed that will see what happens.
>
>>
>> Regards,
>> Jörg
>>
>> --
>> Jörg Steffens joerg.s...@bareos.com
>> Bareos GmbH & Co. KG Phone: +49 221 630693-91
>> http://www.bareos.com Fax: +49 221 630693-10
>>
>> Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
>> Komplementär: Bareos Verwaltungs-GmbH
>> Geschäftsführer:
>> S. Dühr, M. Außendorf, Jörg Steffens, P. Storz
>>
>> --
>>
>> Regards,
>> Jörg
>>
>> --
>> Jörg Steffens joerg.s...@bareos.com
>> Bareos GmbH & Co. KG Phone: +49 221 630693-91
>> http://www.bareos.com Fax: +49 221 630693-10
>>
>> Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
>> Komplementär: Bareos Verwaltungs-GmbH
>> Geschäftsführer:
>> S. Dühr, M. Außendorf, Jörg Steffens, P. Storz
>>
>> You received this message because you are subscribed to the Google Groups "bareos-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to bareos-users...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/bareos-users/qn77vf%24871e%241%40blaine.gmane.org.
>
Reply all
Reply to author
Forward
0 new messages