Cisco Performance Routing (PfR)

Routing protocols select the “best path” using different metrics:

  • RIP uses a hop count
  • OSPF uses cost (based on interface bandwidth)
  • EIGRP uses a composite metric which looks at the bandwidth, delay, load, and reliability on an interface.

Dynamic values in routing protocols like EIGRP’s load and reliability never took off. We want our networks to be safe and predictable so the general recommendation with EIGRP is to stick to static values like bandwidth and delay.

Still, the idea behind routing based on dynamic values is interesting so Cisco created Optimized Edge Routing (OER). OER is not a routing protocol, it requires existing routing but is able to influence your routing by injecting routes. It’s able to select different paths in the network and does this on a per-prefix level. OER looks at different criteria like packet loss, response times, path availability, and traffic load.

OER is a good step forward but it’s not enough, it does “prefix based route optimization” but optimization per prefix is not good enough in today’s world. Nowadays, it’s all about “application based optimization”. Performance Routing (PfR) is very similar to OER but is able to optimize our routing based on application requirements. Technically, OER and PfR are 95% the same but Cisco rebranded OER to PfR.

PfR uses different “phases”, these are the same as the OER phases so I will just explain them in a nutshell here:

  • Profile/Learning: in a typical network, there are a lot of flows and we can’t optimize everything. PfR learns about flows with high throughput and/or delay. A flow that PfR wants to optimize is called a traffic-class. The list with all traffic classes is called the monitored traffic-classes (MTC) list.
  • Measure: collect and calculate performance metrics for the traffic-classes we learned in the profile/learning phase.
  • Apply policy: compare the performance metrics for a traffic-class against certain thresholds to see if a traffic class is in-policy or out-of-policy.
  • Control/Enforce: influence our traffic by injecting routes or by using policy-based routing (PBR).
  • Verify: after making our changes, we keep monitoring the traffic-class to verify performance and make adjustments if needed.

There are two device roles in PfR:

  • Master controller (MC): this is where the magic happens. The MC communicates with all border routers, monitors everything, and does the calculations.
  • Border router (BR): a border router is a router that has one or more interfaces connected to external networks. The BR reports performance metrics to the MC and on this router we implement policies.

The MC doesn’t have to be in the forwarding path, it can be any router in your network. You can also configure the MC and BR on a single router.

PfR uses three interface types:

  • Internal: we use these interfaces to connect to the internal network.
  • External: we use these interfaces to connect to external networks.  You need at least two external interfaces to make PfR work.
  • Local: this is the source interface we use to communicate between the MC and BRs. We often use loopback interfaces for this.

In the remaining of this lesson, I’ll show you how to configure PfR on Cisco IOS routers.

Configuration








We’ll use the following topology:

Cisco Performance Routing Bgp Topology

Let me explain what we have:

  • H1 is a traffic generator that sends traffic to the ISP router loopback interfaces.
  • MC, BR1, and BR2 run iBGP.
  • MC is our master controller.
  • BR1 and BR2 are border routers.
  • Between AS 1 and AS 2 we run eBGP.

We’ll configure PfR so that it automatically learns about the traffic from H1 to ISP1 and optimize it. It will do this by influencing our BGP routing.

Configurations

Want to take a look for yourself? Here you will find the startup configuration of each device.

BR1

hostname BR1
!
key chain PFR
 key 1
  key-string NETWORKLESSONS
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface GigabitEthernet2
 ip address 192.168.123.2 255.255.255.0
 no mop enabled
 no mop sysid
!
interface GigabitEthernet3
 ip address 192.168.24.2 255.255.255.0
 load-interval 30
!
router ospf 1
 network 2.2.2.2 0.0.0.0 area 0
 network 192.168.123.0 0.0.0.255 area 0
!
router bgp 1
 network 192.168.1.0
 network 192.168.123.0
 neighbor 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 1.1.1.1 next-hop-self
 neighbor 3.3.3.3 remote-as 1
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 192.168.24.4 remote-as 2
!
end

BR2

hostname BR2
!
key chain PFR
 key 1
  key-string NETWORKLESSONS
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface GigabitEthernet2
 ip address 192.168.123.3 255.255.255.0
!
interface GigabitEthernet3
 ip address 192.168.34.3 255.255.255.0
!
router ospf 1
 network 3.3.3.3 0.0.0.0 area 0
 network 192.168.123.0 0.0.0.255 area 0
!
router bgp 1
 network 192.168.1.0
 network 192.168.123.0
 neighbor 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 1.1.1.1 next-hop-self
 neighbor 2.2.2.2 remote-as 1
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 192.168.34.4 remote-as 2
!
end

H1

hostname H1
!
interface GigabitEthernet2
 ip address 192.168.1.100 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.1.1
!
end

ISP1

hostname ISP1
!
interface Loopback1
 ip address 10.4.4.1 255.255.255.255
!
interface Loopback2
 ip address 10.4.4.2 255.255.255.255
!
interface Loopback3
 ip address 10.40.40.3 255.255.255.255
!
interface Loopback4
 ip address 10.40.40.4 255.255.255.255
!
interface GigabitEthernet2
 ip address 192.168.24.4 255.255.255.0
!
interface GigabitEthernet3
 ip address 192.168.34.4 255.255.255.0
!
router bgp 2
 network 10.0.0.0
 neighbor 192.168.24.2 remote-as 1
 neighbor 192.168.34.3 remote-as 1
!
ip route 10.0.0.0 255.0.0.0 Null0
!
end

MC

hostname MC
!
key chain PFR
 key 1
  key-string NETWORKLESSONS
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface GigabitEthernet2
 ip address 192.168.123.1 255.255.255.0
!
interface GigabitEthernet3
 ip address 192.168.1.1 255.255.255.0
!
router ospf 1
 network 1.1.1.1 0.0.0.0 area 0
 network 192.168.1.0 0.0.0.255 area 0
 network 192.168.123.0 0.0.0.255 area 0
!
router bgp 1
 network 192.168.1.0
 neighbor 2.2.2.2 remote-as 1
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 3.3.3.3 remote-as 1
 neighbor 3.3.3.3 update-source Loopback0
!
end

Default BGP Routing

Let’s take a look at our current routing. Here’s the BGP table of our MC:

MC#show ip bgp
BGP table version is 4, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 * i  10.0.0.0         3.3.3.3                  0    100      0 2 i
 *>i                   2.2.2.2                  0    100      0 2 i
 * i  192.168.1.0      3.3.3.3                  2    100      0 i
 * i                   2.2.2.2                  2    100      0 i
 *>                    0.0.0.0                  0         32768 i
 r i  192.168.123.0    3.3.3.3                  0    100      0 i
 r>i                   2.2.2.2                  0    100      0 i

We see two entries for the 10.0.0.0/8 network and iBGP uses BR1 as the exit point. We can also check this in the routing table:

MC#show ip route  bgp

      10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
B        10.0.0.0/8 [200/0] via 2.2.2.2, 16:35:51

Let’s also check our border routers:

BR1#show ip bgp

     Network          Next Hop            Metric LocPrf Weight Path
 * i  10.0.0.0         192.168.34.4             0    100      0 2 i
 *>                    192.168.24.4             0             0 2 i
 * i  192.168.1.0      1.1.1.1                  0    100      0 i
 * i                   192.168.123.1            2    100      0 i
 *>                    192.168.123.1            2         32768 i
 * i  192.168.123.0    3.3.3.3                  0    100      0 i
 *>                    0.0.0.0                  0         32768 i
BR1#show ip route bgp

      10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
B        10.0.0.0/8 [20/0] via 192.168.24.4, 16:36:52

Above, we see that BR1 uses its eBGP entry. Here’s BR2:

BR2#show ip bgp

     Network          Next Hop            Metric LocPrf Weight Path
 * i  10.0.0.0         192.168.24.4             0    100      0 2 i
 *>                    192.168.34.4             0             0 2 i
 * i  192.168.1.0      1.1.1.1                  0    100      0 i
 * i                   192.168.123.1            2    100      0 i
 *>                    192.168.123.1            2         32768 i
 * i  192.168.123.0    2.2.2.2                  0    100      0 i
 *>                    0.0.0.0                  0         32768 i
BR2#show ip route bgp

      10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
B        10.0.0.0/8 [20/0] via 192.168.34.4, 16:37:16

BR2 has also installed its eBGP route. Right now, we only have a 10.0.0.0/8 route and iBGP uses BR1 as the exit point to reach AS 2. Wouldn’t it be nice if we can also use BR2 for some traffic?

Performance Routing

Let’s configure Performance Routing. On our interfaces, we need to set the correct bandwidth since this is something PfR takes into account when selecting an exit path. I also change the load-interval to thirty seconds (default value is five minutes) so we calculate the interface statistics more often:

BR1(config)#interface GigabitEthernet3 
BR1(config-if)#bandwidth 128
BR1(config-if)#load-interval 30
BR2(config)#interface GigabitEthernet3
BR2(config-if)#bandwidth 256
BR1(config-if)#load-interval 30

PfR requires a keychain for authentication so let’s add one on the MC and BCs:

MC, BR1 & BR2
(config)#key chain PFR
(config-keychain)#key 1
(config-keychain-key)#key-string NETWORKLESSONS

Let’s configure the master controller. This is where I add my border routers and set the correct interfaces:

MC(config)#pfr master
MC(config-pfr-mc)#border 2.2.2.2 key-chain PFR
MC(config-pfr-mc-br)#interface GigabitEthernet2 internal
MC(config-pfr-mc-br)#interface GigabitEthernet3 external

MC(config-pfr-mc)#border 3.3.3.3 key-chain PFR
MC(config-pfr-mc-br)#interface GigabitEthernet2 internal
MC(config-pfr-mc-br)#interface GigabitEthernet3 external

PfR can be pretty slow, especially in a lab. To speed things up, I tune some of the default timers:

MC(config)#pfr master
MC(config-oer-mc)#holddown 90
MC(config-oer-mc)#backoff 90 180 90
MC(config-pfr-mc)#learn
MC(config-pfr-mc-learn)#periodic-interval 1
MC(config-pfr-mc-learn)#monitor-period 1

Pfr can produce some useful logging messages on the console so I like to enable it:

MC(config)#pfr master
MC(config-pfr-mc)#logging

This completes the configuration of the master controller. The configuration of the border routers is pretty straight-forward:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 786 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

1348 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,


Forum Replies

  1. Hello,

    it was a great lesson very interesting!!!, when I lab ( had to use OER instead) it up, it worked but I came up with a couple of question.

    1. Delay statistics. Default policy is
        resolve delay priority 11 variance 20
        resolve utilization priority 12 variance 20
        and learn 
        throughput
        delay

    using command show oer master border detail, only shows utilization, however in the policy it uses delay also, in fact is priority 11 more than 12 utilization, as in this lab the delay its the same is deciding with utilization, but delay has the highes

    ... Continue reading in our forum

  2. Hi Ignacio,

    If you lab this up, I highly recommend to use PfR. OER is pretty buggy and I had lots of issues with it.

    One command I can think of is show pfr master traffic-class detail:

    MC#show pfr master traffic-class detail 
    OER Prefix Statistics:
     Pas - Passive, Act - Active, S - Short term, L - Long term, Dly - Delay (ms),
     P - Percentage below threshold, Jit - Jitter (ms), 
     MOS - Mean Opinion Score
     Los - Packet Loss (percent/10000), Un - Unreachable (flows-per-million),
     E - Egress, I - Ingress, Bw - Bandwidth (kbps), N - Not applicable
     U - unknown, * - 
    ... Continue reading in our forum

  3. Hello,

    Is it possible to use PFR when you are receiving default routes from a service provider or this can only be effective when the full routing table is being received?

  4. Hello Tariq

    PfR will function regardless of whether or not the ISP simply sends you a default route or more routing information. The policy that is used to determine the routing is based on the traffic itself and not on whether or not it is a default route. In the lesson, the PfR is actually used to balance the use of traffic between the multiple exit points from the local AS. This is why at least two external interfaces are required to make PfR work.

    I hope this has been helpful!

    Laz

3 more replies! Ask a question or join the discussion by visiting our Community Forum