PfR symmetry

Question

Dear All,
I am mid way through delivery of an MPLS network for a customer. We have the option of adding a DMVPN internet backup. The WAN routing protocol is BGP for both DMVPN and MPLS (MPLS is straight routing - no overlay or getvpn)
The customer has some pretty odd ideas about how to use the service, mainly they are very paranoid about oversubscibing the MPLS link for their "golden" application, so have come up with all kinds of weird and wacky solutions that they call "requirements". As a result, they have the idea that they cannot route all traffic over MPLS, and instead want to create a mix of route filter, PBR, NAT, ACL and all kinds of horrible things to keep the MPLS link "sacred".
I would like to guide them to use the service in a better way leveraging PfR, something simple to start with like:
- use MPLS all of the time by default
- when it reaches 80% utilisation, switch the non-critical traffic to DMVPN yet keep the "golden" app on MPLS
- this policy is applied at both branch and hub BRs
I have read this cisco wiki (it is rather good!!!!):
http://docwiki.cisco.com/wiki/PfR:Solutions:EnterpriseDualVPN#PfR_performance_and_load_policy_test_case
Where I get a bit lost is in the symmetry. Is it symmetrical?
For example, if a branch MPLS link hits 81% outbound utilisation, then uses dynamic PBR to switch outbound traffic to VPN. Sorted! but what about the inbound? If that is hitting 81% also. What does PfR do?
This is where I get a bit lost. For the inbound to branch, the hub must do something surely? Consider the MPLS capacity is 100M - the 8.1M to the branch is in policy so should keep forwarding via MPLS. How does it know that the branch is OOP?
If it doesn't do that, you end up with assymetric traffic (branch outbound DMVPN, inbound MPLS).
Am I missing something here? Any advice you can give us much appreciated.
Thanks a million! 
Phil

Answer 1

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
Ah, well my experience with asymmetrical routing has often been with similar bandwidth paths, so it's not normally a problem unless there's some "stateful" device between hosts.  But I can see why inadvertent transit via VSAT might be considered a problem.  ;)
I think PfR can help us with the outbound traffic from branch, but I struggle to see how it can help with the inbound IF using utilization only on HUB BR - agree it would never go out of policy (10M to a single branch means the hub is only at 10%).
Ah, it works because, as noted, PfR will see the jump in latency (passively and/or actively) to the destination if you have it do more than monitor egress port utilization.  (When I had used OER/PfR, I had international multipoint.  So "in" congestion to any one site could be caused by the aggregate of multiple other sites "out" to it.
With active monitoring, PfR would see the MPLS link latency worse than your VPN backup (to same destination), and when it does, juggle traffic flows.
No, don't have experience with using PfR's inbound control (at the time I set it up, most of my devices only supported OER, and inbound isn't an option with OER).
Also cannot say what's typical "real world". I can say, when I setup "my" OER/PfR, our network monitoring section complained almost all our WAN performance problems disappeared.  (Laugh - we then had to work out how to "see" WAN performance problems in spite of OER/PfR.)