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?
WBR
If you're using 2.3.33, SO_KEEPALIVE 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.
On 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?
WBR
Dmitriy Kirhlarov OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia P:+7 495 105 7247 ext.208 F:+7 495 105 7246 E:DmitriyKirhlarov@oilspace.com Building Successful Supply Chains - One Solution At A Time. www.oilspace.com
Aaron Richton wrote:
If you're using 2.3.33, SO_KEEPALIVE 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, SO_KEEPALIVE 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 OpenLDAP Core Team
SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
Pierangelo Masarati wrote:
Aaron Richton wrote:
If you're using 2.3.33, SO_KEEPALIVE 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, SO_KEEPALIVE 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.
Howard Chu wrote:
Pierangelo Masarati wrote:
Aaron Richton wrote:
If you're using 2.3.33, SO_KEEPALIVE 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, SO_KEEPALIVE 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_DOWN (or LDAP_TIMEOUT, in some cases) the connection is tainted.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
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 OpenLDAP software.
On 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 OpenLDAP 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
openldap-software@openldap.org
-
Aaron Richton -
Dmitriy Kirhlarov -
Howard Chu -
Pierangelo Masarati