• Replication via syncrepl, the LDAP content synchronization operation (LDAP sync, RFC 4533). Introduced in OpenLDAP 2.2, it operates in pull mode: the consumer pulls the updates out of the producer. When used in refreshOnly mode, the producer barely knows it's acting as a master, while the refreshAndPersist mode requires the producer to support persistent searches. Either mode requires the provider and the consumer to support the controls related to the Sync Operation.
• Replication via the slurpd daemon; inherited from UMich's LDAP. It operates in push mode: the master pushes changes to the slaves. Slurpd replication is considered obsolete. It is deprecated in favor of syncrepl replication and is being phased out. It will be completely dropped in 2.4.

Why are client modifications being made to the slave SLAPD instead of being referred to the master?

Why aren't the clients chasing the update referral returned by the slave SLAPD?

Why can't the updatedn modify the slave?

Answers specific to slurpd:
How do I add slaves?
How many replogs should I use?
Why don't my changes on a slave directory get referred to the specified master?

Answers specific to syncrepl:
How do I replicate my entire LDAP tree using Syncrepl?
How do I auto-restart replication if I'm using "refreshAndPersist" mode?
What does "sessionlog" directive do?
How to automatically chase referrals on a syncrepl slave
How to have a slave proxying changes to the master
How to set up syncrepl using tls certs (sasl external bind)
New Item