NAVIGATION
CATEGORIES
REFERRENCE
LINKS
replication. keepalive searching...
6 answers - 612 bytes -
Hi, list.
I'm using openldap 2.3.33 on provider and consumer server on FreeBSD
6.x.
Provider have real IP address. Consumer installed in local network
with 172.16.x.x address behind Cisco Pix firewall with NAT. I'm using
syncrepl replication (type=refreshAndPersist retry="500 +") and all
work fine.
But, time-to-time, after reconfiguration, we are reloading translation
table on PIX. As result, all installed tcp connections silently drops.
Consumer detect this situation after more them 1h (TCP timeout?). Is
it possible decrease this time period?
WBRNo.1 | | 859 bytes |
| 
If you're using 2.3.33, SKEEPALIVE should be set (see the ITS and
CHANGES). You can look at your FreeBSD documentation to determine how to
tune the kernel TCP parameters thereof.
Fri, 9 Feb 2007, Dmitriy Kirhlarov wrote:
Hi, list.
I'm using openldap 2.3.33 on provider and consumer server on FreeBSD
6.x.
Provider have real IP address. Consumer installed in local network
with 172.16.x.x address behind Cisco Pix firewall with NAT. I'm using
syncrepl replication (type=refreshAndPersist retry="500 +") and all
work fine.
But, time-to-time, after reconfiguration, we are reloading translation
table on PIX. As result, all installed tcp connections silently drops.
Consumer detect this situation after more them 1h (TCP timeout?). Is
it possible decrease this time period?
WBRNo.2 | | 805 bytes |
| Dmitriy Kirhlarov wrote:
Hi, list.
I'm using openldap 2.3.33 on provider and consumer server on FreeBSD
6.x.
Provider have real IP address. Consumer installed in local network
with 172.16.x.x address behind Cisco Pix firewall with NAT. I'm using
syncrepl replication (type=refreshAndPersist retry="500 +") and all
work fine.
But, time-to-time, after reconfiguration, we are reloading translation
table on PIX. As result, all installed tcp connections silently drops.
Consumer detect this situation after more them 1h (TCP timeout?). Is
it possible decrease this time period?
Typically the TCP keepalive timeout is a kernel-specific setting. Look in
your FreeBSD documentation, it's not something we can control in the LDAP
software.No.3 | | 1106 bytes |
| Aaron Richton wrote:
If you're using 2.3.33, SKEEPALIVE should be set (see the ITS and
CHANGES). You can look at your FreeBSD documentation to determine how to
tune the kernel TCP parameters thereof.
AFAIR, SKEEPALIVE isn't the solution as on most systems it defaults to
a couple of hours, and manuals usually suggest to leave it untouched to
avoid instabilities (no more details at hand right now).
In a custom development where proxies are involved, we designed a
background thread that periodically performs a simple operation on all
proxy cached connections and, in case of failure, trashes the cached
connection. Maybe something similar could be set up for syncrepl as
well, since in principle multiplexed operations should be possible on
the connection created for sync replication.
p.
Ing. Pierangelo Masarati
LDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati (AT) sys-net (DOT) itNo.4 | | 993 bytes |
| Pierangelo Masarati wrote:
Aaron Richton wrote:
>If you're using 2.3.33, SKEEPALIVE should be set (see the ITS and
>CHANGES). You can look at your FreeBSD documentation to determine how
>to tune the kernel TCP parameters thereof.
AFAIR, SKEEPALIVE isn't the solution as on most systems it defaults to
a couple of hours, and manuals usually suggest to leave it untouched to
avoid instabilities (no more details at hand right now).
In a custom development where proxies are involved, we designed a
background thread that periodically performs a simple operation on all
proxy cached connections and, in case of failure, trashes the cached
connection. Maybe something similar could be set up for syncrepl as
well, since in principle multiplexed operations should be possible on
the connection created for sync replication.
p.
Interesting idea. I suppose a query on the rootDSE would suffice.No.5 | | 1750 bytes |
| Howard Chu wrote:
Pierangelo Masarati wrote:
>Aaron Richton wrote:
If you're using 2.3.33, SKEEPALIVE should be set (see the ITS and
CHANGES). You can look at your FreeBSD documentation to determine how
to tune the kernel TCP parameters thereof.
>>
>AFAIR, SKEEPALIVE isn't the solution as on most systems it defaults
>to a couple of hours, and manuals usually suggest to leave it
>untouched to avoid instabilities (no more details at hand right now).
>>
>In a custom development where proxies are involved, we designed a
>background thread that periodically performs a simple operation on all
>proxy cached connections and, in case of failure, trashes the cached
>connection. Maybe something similar could be set up for syncrepl as
>well, since in principle multiplexed operations should be possible on
>the connection created for sync replication.
>>
>p.
Interesting idea. I suppose a query on the rootDSE would suffice.
In the proxy case, we typically query the suffix of the proxied tree
with base scope and filter "(|)" where supported, or
"(!(objectClass=*))" otherwise, to minimize the activity on the remote
server. In case of LDAP_SERVER_DWN (or LDAP_TIMEUT, in some cases)
the connection is tainted.
p.
Ing. Pierangelo Masarati
LDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati (AT) sys-net (DOT) itNo.6 | | 501 bytes |
| Fri, Feb 09, 2007 at 07:46:33AM -0800, Howard Chu wrote:
Typically the TCP keepalive timeout is a kernel-specific setting.
Look in your FreeBSD documentation, it's not something we can
control in the LDAP software.
I change TCP keepalive sysctl from 2h to 10m and will test it, but, I
think, it's not a good solution, because, it's apply to all
connections and for all services.
May be, more good idea make "ping" inside replication process?
WBR
QUESTION ON "Networking"
- No forms all orders filled
- How to copy shared folders from one cyrus to another?
- Question about SLAs
- net-snmp move to SVN. Objections?
- Searching for entryUUIDs broken?
- More stock spam + strange cf files
- Question about SLAs
- selfcheck request failed
- selfcheck request failed
- Spam filtering on SA list?
- Limits on address expansion
- Hardware Compatibility Question...
- FreeRadius + OpenLDAP (SMD5) + Windows XP
- MySQL support in Windows binary of FreeRadius
- Announce: Net-LDAPapi version 2.00 released
- Plugin development places / repositories
- LDAP authenticaton against PAM how-to
- more compile help questions...
- Limit of "to" or "cc" by a sender
- 6VPE IOS