My company is one of the early CDR adopters, and over the years we've had various issues with replication depending on a MULTITUDE of factors - network blips, memory issues on source and destination servers, etc. The list goes on.
In general, it seems that once something interferes with log transmission when a pair is in Replicating state you will start seeing discrepancies. The worst case is when the source has tracked the changes, dumped them into logs, and then the logs don't end up being properly replayed - at that point even a SmartSync may not catch the change since it wasn't flagged as needing to be transmitted.
Due to audit requirements we now have 2 ways of dealing with this. First we converted our CDR replication sets to Remote Backup mode. Due to WAN constraints saying replication was "near real time" was simply not true, and we did not need THAT tight a replication window anyways. We simply schedule CDR Remote Backup "jobs" every 3 hours during the day. This completely eliminates the whole log creation/replay thing. CDR does essentially a SmartSync "plus" and we have had little to no issues with source/destination parity in this mode. Second, working with CV support we are using a utility they are working on that compares source and destination and will flag any discrepancies to be corrected by the next SmartSync. With any luck they will add this functionality to Simpana 9 but who knows.
Either way, my 1st recommendation is to evaluate whether or not you truly need that near real time RPO for replication. In our case CDR replicates branch office data to our central datacenter for DR and our long-term retention requirements. If, however, you need a true hot or warm site you will need to stick with Continuous mode, give it lots of bandwidth, and work with CV support on how to periodically run source/destination compares to ensure things are in sync.