Cause: The multi-master replication protocol keeps a cumulative counter of the relative time offsets between servers. If the system time is adjusted by more than one day (ntp issues, vm issues), the counter will be off by more than one day.
Consequence: A replication consumer will refuse to accept changes from a master that has a time offset more than 1 day. Replication will be broken from that supplier to the consumer.
Fix: A new configuration attribute was added to cn=config - nsslapd-ignore-time-skew. The default is "off". If this attribute is set to "on", a replication consumer will allow replication to proceed despite excessive time skew. An error message will still be logged, warning the admin about the time skew issue.
Result: When nsslapd-ignore-time-skew is set to "on", replication will proceed despite excessive time skew.