Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
If you have a single flow, such as your replication, that will practically saturate a path, PfR cannot do much for that flow, but it can at least separate that flow and your others across multiple paths, i.e., again, dynamic load balancing. (What you might see is replication just on one path and other all traffic on the other.)
PfR can manage both ingress and egress bandwidth, but ingress is much more complex because somehow you need to inform the other side how to route traffic to you.
I'm unfamiliar mixing versions of PfR.
On earlier IOS versions, before licensing, I recall PfR required a better than IP Base feature set. So, it's likely to require some additional license on later IOS versions.
BTW,
David mentions increased CPU load and sizing a MC correctly. My experience with OER and 1st gen PfR (I haven't use the later versions - I've since starting working at a different company that doesn't use it), neither imposed much additional CPU load and at my branches I ran MC on one the edge devices. I only used dedicated MCs at the HQ hub and in hind sight, don't believe I really needed them. That said, what I did run into, was usage of lots of RAM if I had active monitoring. The latter depends much on how granular you monitor flows.
