Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

OER/PfR.How to synchronize?

Hi all,

Please take a look at this situation:

One company have two offices : central and remote.

Offices  have two routers (master and backup) each.

Master routers connecting offices using  VPN L3 BGP with ISP1.

Backup routers connecting offices using VPN L3 BGP with ISP2.

Both offices routers PfR configuration is same.

 

Q:

How to provide simultaneous PfR switching  on the both ends to prevent asymmetric data flow?

 

 

6 REPLIES
Super Bronze

DisclaimerThe Author of this

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

Might not be possible as OER/PfR, by design, moves flows "about".

 

At L3, asymmetic flows shoud be a non-issue.

New Member

Thanks for the quick answer

Thanks for the quick answer Joseph.

But, my question reason is an issue.

My company use PfR about two years, and it works fine. Exclude logs growing rate))).

But at last Friday we have lost a portion of critical data.

At that timepoint,  ISP1 has up to 70% packet loss , and central office's PfR  switched earlier than  remote office's. I think, data from remote office was lost in time between central and remote offices  PfR switching.

So, I'm not sure in PfR now.

Super Bronze

DisclaimerThe Author of this

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

Are you using active monitoring?  If not, PfR much slower to notice issues.  Also, it's possible there's ISP issue was in one direction and not the other, so two side might react differently.

HelloAs you have stated PfR

Hello

As you have stated PfR is only applied on the office routers so this would performance route I assuming on the higher delay value of the wan links and and select  the lower delayed path.

So my I understanding then this will only be apllicable to the office side, unless you can advertised a lower metric over to your remote offices for the proffered path Prf has negotiated.

Also when you say the configuration is the same on each office router are your referring to the PfR borders only?

 

res

Paul

Please don't forget to rate any posts that have been helpful. Thanks.
New Member

PfR is a fantastic tool, but

PfR is a fantastic tool, but it is not without it's challenges.  There are a couple of things that may be helpful.

There are a few techniques for trying to handle this situation.

1) MOS - Mean Opionion score is one methodology.  While this is intended to rate the quality of the circuit for voice use, the rating scale for MOS can be altered.You can set the learning state to impose a minimum MOS score for the circuit.

2) PfR is not asymetric by definition, rather it uses the best circuit based on the characteristic defined for each direction of travel.  At the time I was setting up PfR it had a few limitations.  One was that it would use a percentage of bandwidth between circuits, and not the actual bandwidth.  The problem comes into play when you have a 1 MB circuit and a 10 MB circuit.  The solution I came up with in this scenario was to default traffic down the 10 MB circuit until the bandwidth 90%; i.e. both circuits had 1 MB of bandwidth remaining.  On top of this solution we have a low latency filter which would pick off low latency traffic and send it down the circuit with the better response time. The bottom line is that in this scenario most if not all of the bulk traffic went down the preferred pipe line.  There are other challenges similiar to this, but as you can see in this scenario you can set thresholds for when PfR should be enabled and unitl that time the traffic will use the desired route.

3) Keep Alives - This can be performed in a couple of different manners.  One for example is with keepalives. For our VPN tunnels we configured 3 keepalives at 7 second intervals to trip the circuit in 21 seconds in the event of a tunnel down, interface up scenario.  In a case with high packet loss it would cause the circuit to cycle which should also trigger an alarm.  I have also noticed during these types of events packet loss is often much higher with increased packet size.  I don't know if it is an option, but it would be nice to be able to configure a keep alive with a 1024k packet size rather that 64 bit.

4) IP SLA - In addition to keepalives my understanding is that Cisco has put alot of effort into IP SLAs and I believe the newer IOS versions are including these possible as a default.  Again not a perfect solution, but better.

5) Lastley we use a tool known as what's up gold to assist with PfR.  The problem with many tools is that with PfR enabled tools that simply ping the network are inadequate.  What's up gold will let you monitor the interface, errors on the interface, and you can set a level of dropped packets.  All of these thresholds are invaluable when setting up PfR.

The blessing of PfR, is that when this challenge is detected, you can quickly and easily down the circuit, and turn it back up when the problem is corrected.

Hope some of these ideas help.

Super Bronze

DisclaimerThe Author of this

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

Just some thoughts .  . .

#1 MOS is indeed a nice method of active monitoring as it effectively is measuring latency, jitter and drops.

 

#2 I've done similar if I don't have some way to "statically pre-balance" load share when links capacity varies much.  For example, I once had a case of a T3 and T1 on different WAN edge routers.  The WAN edge routers were also the site's only routers so I was able to use GLBP to proportionally balance the gateways in about the same ratio.  Then PfR would dynamically balance the two links, also proportionally.

 

#3 When using tunnels that support keep alives, I've successfully used 1,3 (i.e. lost detection in 3 seconds), but the trick is to also use QoS so that keep alive packets are not needlessly delayed or lost.

 

#4 NB: PfR uses IP SLA for its active monitoring

 

#5 Laugh - indeed PfR will mask WAN issues.  When I first started using it, SNMP network monitoring guy said all our monitoring tools no longer showed any WAN issues.  (That was the bad news, good news was, our users no longer saw performance WAN issues either.  smiley)

 

What we ended up doing was using a tool that also generated/managed IP SLA on the WAN edge routers using the external interface IPs as endpoints (i.e. bypassing PfR "masking" our testing results) and we also had scripts to look for "interesting" log messages generated by PfR.

82
Views
0
Helpful
6
Replies
CreatePlease to create content