RIP, EIGRP, OSPF, IS-IS, BGP, MPLS, VTP, STP.
User avatar
dieselboy
Post Whore
Posts:
2731
Joined:
Tue Aug 05, 2008 6:36 am
Certs:
CCNP, CCNA Voice, SMB Select, Linux+

PfR working knowledge

Sat Apr 21, 2012 11:07 pm

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!
Meanwhile, back in the city...

User avatar
mellowd
CCIE #38070
Posts:
13814
Joined:
Wed Jun 18, 2008 7:49 am
Certs:
CCIE (RS,SP), JNCIE-SP, BC-/SPNE/NP

Re: PfR working knowledge

Sun Apr 22, 2012 1:25 am

Only in a lab unfortunately

User avatar
dieselboy
Post Whore
Posts:
2731
Joined:
Tue Aug 05, 2008 6:36 am
Certs:
CCNP, CCNA Voice, SMB Select, Linux+

Re: PfR working knowledge

Sun Apr 22, 2012 8:19 am

mellowd wrote:Only in a lab unfortunately


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.
Meanwhile, back in the city...

User avatar
burnyd
Post Whore
Posts:
3159
Joined:
Fri Nov 13, 2009 5:15 pm
Certs:
CCIE R&S/SP,CCNP-SP,JNCIA,VCP510,VCA-DCV

Re: PfR working knowledge

Sun Apr 22, 2012 8:56 am

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.
http://danielhertzberg.wordpress.com - I blog about networks!

User avatar
mellowd
CCIE #38070
Posts:
13814
Joined:
Wed Jun 18, 2008 7:49 am
Certs:
CCIE (RS,SP), JNCIE-SP, BC-/SPNE/NP

Re: PfR working knowledge

Sun Apr 22, 2012 9:28 am

dieselboy wrote:
mellowd wrote:Only in a lab unfortunately


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.



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

just2cool
Member
Posts:
137
Joined:
Fri Dec 24, 2010 12:11 am
Certs:
Expired 350-001

Re: PfR working knowledge

Sun Apr 22, 2012 2:46 pm

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.

zerojunkie
Senior Member
Posts:
369
Joined:
Mon Jan 26, 2009 5:59 pm

Re: PfR working knowledge

Sun Apr 22, 2012 6:14 pm

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.

User avatar
dieselboy
Post Whore
Posts:
2731
Joined:
Tue Aug 05, 2008 6:36 am
Certs:
CCNP, CCNA Voice, SMB Select, Linux+

Re: PfR working knowledge

Sun Apr 22, 2012 7:47 pm

just2cool wrote: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'll bear this in mind but hopefully version 3.x is stable?

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.

I was thinking of using with BGP in honesty. Thanks for the advice on the UDP jitter probes. Would a scenario work if two BR were actually MC in redundancy as well?

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.

My idea for one instance is that if one site routes outbound via one circuit, then I would want the remote circuit to also route via that same path for return traffic. I suppose another view could be that a full duplex circuit with 2 sites and 2 MPLS circuits to each could be thought of as eight individual paths in an MPLS environment (four paths for point to point links).But thinking about it, it wouldn't really matter as long as traffic was taking the best path - which is the purpose of PfR..

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

User avatar
davidrothera
Ultimate Member
Posts:
992
Joined:
Thu Jan 13, 2011 5:10 pm
Certs:
CCIE R&S #38338, CCNP, CCIP

Re: PfR working knowledge

Mon Apr 23, 2012 8:01 am

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

just2cool
Member
Posts:
137
Joined:
Fri Dec 24, 2010 12:11 am
Certs:
Expired 350-001

Re: PfR working knowledge

Mon Apr 23, 2012 7:52 pm

I'll bear this in mind but hopefully version 3.x is stable?
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.

I was thinking of using with BGP in honesty. Thanks for the advice on the UDP jitter probes. Would a scenario work if two BR were actually MC in redundancy as well?
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.

My idea for one instance is that if one site routes outbound via one circuit, then I would want the remote circuit to also route via that same path for return traffic. I suppose another view could be that a full duplex circuit with 2 sites and 2 MPLS circuits to each could be thought of as eight individual paths in an MPLS environment (four paths for point to point links).But thinking about it, it wouldn't really matter as long as traffic was taking the best path - which is the purpose of PfR..
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.

User avatar
dieselboy
Post Whore
Posts:
2731
Joined:
Tue Aug 05, 2008 6:36 am
Certs:
CCNP, CCNA Voice, SMB Select, Linux+

Re: PfR working knowledge

Mon Apr 23, 2012 11:31 pm

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.
Meanwhile, back in the city...

User avatar
mellowd
CCIE #38070
Posts:
13814
Joined:
Wed Jun 18, 2008 7:49 am
Certs:
CCIE (RS,SP), JNCIE-SP, BC-/SPNE/NP

Re: PfR working knowledge

Tue Apr 24, 2012 1:43 am

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

User avatar
dieselboy
Post Whore
Posts:
2731
Joined:
Tue Aug 05, 2008 6:36 am
Certs:
CCNP, CCNA Voice, SMB Select, Linux+

Re: PfR working knowledge

Tue Apr 24, 2012 2:37 am

mellowd wrote: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


Top man :D
Thanks
Meanwhile, back in the city...

'

Return to Cisco Routing and Switching

Who is online

Users browsing this forum: No registered users and 26 guests