Does anyone on the forum have hands on knowledge of PfR? If so how did / do you find it in your environment, is it fit for purpose? Any issues or quirks?
What setup did you use it with? Version 2 or 3?

I've been doing some serious reading on the subject this past week, and would like to get some input on someone that has used it in real life!

_________________
"Right actions in the future are the best apologies for bad actions in the past."

Only in a lab unfortunately

_________________
www.mellowd.co.uk/ccie/

Question then: as this only controls outbound routing, if you have two sites sending traffic to each other you would then need two separate PfR areas, each with their own MC. I don't see how this would be possible or even feasible managing for example, two disparate routers across a resilient WAN with just one Master Controller.

_________________
"Right actions in the future are the best apologies for bad actions in the past."

This is something I plan on testing within the next few weeks. I have only done it for the INE labs just home lab like testing. It looks like it might actually work out for me for some of our remote sites since we have 2 mpls circuits going back to our data center where both circuits hand out a default route.

_________________
"I will prepare and some day my chance will come." - Abraham Lincoln
http://danielhertzberg.wordpress.com - I blog about networks!

I don't think you can do that. If you want that kind of power you'll need openflow PfR is a lot like OpenFlow in certain regards. For example the MC doesn't actually need to be in the path of any actual traffic. All it's doing is making decisions. which makes you think that a powerful server/cluster somewhere could probably do a better job. All it needs is connectivity to the border routers.

Which makes is sound more and more like what openflow is trying to do

_________________
www.mellowd.co.uk/ccie/

After several months of testing, I deployed this years ago on a huge global network. It took forever to deploy since we had to first wait for a stable release of code (there were lots of bugs -- including MCs rebooting).

I'm not understanding your confusion? Yes, it only controls outbound routing by setting localpref (please don't use OSPF for this). You should use IP-SLA UDP jitter probes, the rest aren't as good. This feature is very useful if you connect to multiple MPLS SPs and want to decide on which one to avoid based on current conditions. You can have more than one MC for redundancy, and that MC can act as a BR/forward traffic too if you prefer.

Why would you only want one PfR instance? They're supposed to act independently based on conditions for that local network, and the last thing you would want is a MC that sits across the same shitty SP that you're trying to avoid in the first place. Keep in mind that this feature was designed to scale for thousands of sites, not just a couple.

We're very slowly dipping our toes into PfR @ work. For a cisco technology, it has a lot of commands to control how it behaves, but I still get the distinct feeling that you don't have enough control over what's really going on. It's a bit slow to notice topology changes unless you use IP SLAs since the min-value on whatever command makes changes to your network is 90 seconds. Other than that though, it's ok for what we're using it for (routing non-critical traffic over cheaper transit). Also iirc, you can control inbound through AS prepends, but I never tried to in the lab.

Thanks, this is exactly the kind of response I was after. See above comments in the quote.

_________________
"Right actions in the future are the best apologies for bad actions in the past."

You can use PfR for inbound traffic management now as well so you could use that for controlling which circuit is used but this would rely on attributes that you could set being visible by both circuits on both sites.

_________________
---
David
CCIE R&S #38338, CCIP, CCNP

http://networkbroadcast.co.uk - My Blog
http://twitter.com/davidrothera

Rest assured that I worked on this project in 2008/09 -- they've fixed a lot of things since then (and it was version 2 obviously). It was usable in 2009 for us. Having said that, I would highly recommend typing "pfr" in bug toolkit for your code. There is no such thing as code without bugs -- but you can usually find code that doesn't have any bugs affecting your specific needs. Here is one bug on a 7200 running 15.1 and PfR v3:
Symptoms: Memory leaks on OER border router while running PfR-IPSLA configuration.
Conditions: This symptom is seen on a Cisco 7200 router that is running Cisco IOS Release 15.1(4)M.
Workaround: There is no workaround.

Good choice. I tested all kinds of topologies -- 2 dedicated 7200 NPE-G2s running as dedicated MCs with 4 BRs, 2 BR/MCs, 1 BR/MC with 3 BRs ... all of it worked. We ended up using dedicated MCs in prod, though. I tested 3800s, 7200s as both BR and MC ... and sup720s and 2800s only as BR.

Makes sense. I'll tell you from experience though -- SPs are notorious for screwing things up in one direction. Also, keep in mind that probes are sent out of each BR exit interface. So, say you have an MPLS cloud with 4 branches hanging off of it. If one branch begins to have issues out of primary MPLS and backup MPLS cloud is better. If PfR prepends your routes outbound, all of your branches are going to use the backup path even if the other 3 were ok. IMO, if you control both sites and have SP clouds in the middle, then I would just do what PfR/OER was originally designed to do -- outbound traffic optimization. It would have avoided this problem.

If you want simplicity/have P2P links, it looks like cisco came out with inbound traffic optimization in 2010 -- all it does is either set an AS prepend or community.

Just2cool - thank you very much. Excellent stuff, much appreciated.

One thing though, I've found it very difficult to locate which PfR version is contained within which IOS. I've gone as far as enabling PfR (actually OER on one of the routers as it's old) to find the version, but it doesn't seem to tell you which until it is communicating with a BR or MC (thinking about it, this makes sense).

I've looked in feature navigator and it just states PfR or OER without any versions. I understand that 15.0 or 15.1 contains Version 3.x so have made assumptions on that regarding older IOS versions.

I forgot to mention - I'm all for simplicity. In any design, my underlying goals are to build and design in a way which allows someone else in the future to administer, logically, looking at diagrams and the existing network.

_________________
"Right actions in the future are the best apologies for bad actions in the past."

12.4(15)T is version 2.1
12.4(24)T is version 2.2 (which comes with PIRO)
15.0 + is 3.0 I believe

_________________
www.mellowd.co.uk/ccie/

Top man
Thanks

_________________
"Right actions in the future are the best apologies for bad actions in the past."