OER/PfR Part 1: Set Up

As of the version 4.0 blueprint OER/PfR is now being tested in the CCIE Routing & Switching lab exam. Since IOS release 12.4T Cisco renamed the technology previously called OER (Optimized Edge Routing) to PfR (Cisco Performance Routing). In the rest of this article and series the term PfR is used. The current command set is still using ‘oer’ but Cisco announced that this will become deprecated at some time.

The basic principle behind it, is that you, as an enterprise have multiple uplinks or even routers to the internet or SP backbone network where all your branch offices connect. Now in the modern networks you can’t rely on the line-protocol of an interface anymore, thus meaning you have to make sure you have an end-to-end check if your networks are still reachable. IGP’s are designed that always the path with the lowest cost and therefore the highest bandwidth is preferred. If you happen to have experience in the field on this, you might know that ISP’s always oversubscribe their links and therefore the fastest uplink is definitely not always the best. Due to congestion, maintenance or problems in the SP network you get bad performance in your own network. The redundant uplink is therefore not used as the metrics determined that the path is not as fast as the primary link.

PfR is build to overcome this problem and by doing several measurements the ‘best’ path is chosen (read not always the fastest). You can for example determine that VoIP and Video traffic should use another SP uplink as the bandwidth is not that much, you agreed several QoS policies on that link and traffic will be much more assured to arrive than on the fast non-QoS link.

Another technique we know that can do this is MPLS Traffic Engineering. It has less built-in features, but the basic idea is the same, though TE is designed to work within one network and even more specific in one area.

PfR has thousands of possibilities and hundreds of commands. If you want it could become extremely complex if you use several measurements and differentiate several links to use for different purposes. For the R&S lab exam I would expect that only the basic principle is tested and you have to be familiar with the technology. We are implementing this in a couple of our Vol.2 labs, so stay tuned for updates on that!

For the rest of all the geeky features: Know where to look it up! There is even a separate configuration guide available for PfR:

http://www.cisco.com/en/US/docs/ios/oer/configuration/guide/12_4t/oer_12_4t_book.html

PfR uses a strict ‘phased’ implementation so you are always certain to use the best values for your network and it gives you a good insight in the preferred working method. The image below is taken from the Cisco IOS Optimized Edge Routing Configuration Guide

Figure 1

During this series we will use these phases to explain how PfR works.

In this first article we will define all the steps necessary for getting PfR to work and set-up the necessary components and define interfaces.

The topology shows that we have 3 connections to our branch office (R9), 2 are transparent links, we don’t know how or what kind of Service Provider equipment is in the path and we have a third connection, trough an ISP with PPP connections were we are sure that it’s only 1 SP network.

Figure 2

PfR is designed to have 1 device that manages the entire setup; this includes pushing IGP or BGP information into the network and informing the other routers what to do.  This router is called the Master Controller and this is the single location where you configure the policies after which they are pushed to the other routers.

The other routers that carry uplinks to the SP networks are called Border Routers. These devices are very easy to setup, as they only need information on where the MC is located. It’s possible to combine these roles in one device, which could be useful in smaller networks.

First we configure all necessary connectivity configurations and do a quick check if our layer 2 is working.

R2(config-if)#do ping 100.1.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.1.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/16 ms
R2(config-if)#do ping 100.1.124.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.1.124.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
R2(config-if)#do ping 100.1.29.9 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.1.29.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
R2(config-if)#do ping 100.1.26.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.1.26.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/17/20 ms
R2(config-if)#
R2(config-if)#do sh ip int brie | ex unas
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/1/0.1              100.1.26.2      YES manual up                    up
FastEthernet1/0            100.1.124.2     YES manual up                    up
FastEthernet1/1            100.1.29.2      YES manual up                    up
R6(config-subif)#do sh ip int brie | ex unas
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/1/0.1              100.1.26.6      YES manual up                    up
Multilink1                 100.1.69.6      YES manual up                    up
R6(config-subif)#do ping 100.1.69.9
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.1.69.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R6(config-subif)#do sh ip route  con
100.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C       100.1.69.0/24 is directly connected, Multilink1
C       100.1.69.9/32 is directly connected, Multilink1
C       100.1.26.0/24 is directly connected, Serial0/1/0.1
R6(config-subif)#

Next we configure the ‘border routers‘, we start with these, as the configuration is very easy. To ensure no rogue devices will screw up our PfR setup, it’s possible to configure authentication. We connect over the loopback addresses and therefore it’s necessary to specify the interface were we want to source the communication from.

R2 & R4
!
key chain OER_AUTH
key 1
key-string IPEXPERT
!
oer border
local Loopback0
master 100.1.1.1 key-chain OER_AUTH
R4(config)#do sh oer border
OER BR 100.1.4.4 ACTIVE, MC 100.1.1.1 UP/DOWN: DOWN
Conn Status: CONNECT FAILED
OER Netflow Status: ENABLED, PORT: 3949
Version: 2.2  MC Version: 0.0
Exits

As you can see, not really intelligent stuff on the border routers, really everything is controlled from the master. When the session to the master is not ‘up’ yet, the border doesn’t know anything. Not even which interfaces are participating.

Last is to configure the ‘master controller‘.

Besides configuring the borders in this network, you also need to specify which interfaces are used for communication with the SP and which are for internal use. These are interface names on the border routers and not on the master.

R1
!
key chain OER_AUTH
key 1
key-string IPEXPERT
!
oer master
logging
!
border 100.1.2.2 key-chain OER_AUTH
interface FastEthernet1/0 internal
interface FastEthernet1/1 external
interface Serial0/1/0.1 external
!
border 100.1.4.4 key-chain OER_AUTH
interface FastEthernet0/0 internal
interface FastEthernet0/1 external

After configuring the master we see the neighbor sessions coming up, to see this information it’s necessary to enable ‘logging’ under the OER process.

*Sep  6 13:01:26.113: %OER_MC-5-NOTICE: BR 100.1.2.2 UP
*Sep  6 13:01:26.125: %OER_MC-5-NOTICE: BR 100.1.2.2 IF Se0/1/0.1 UP
*Sep  6 13:01:26.165: %OER_MC-5-NOTICE: BR 100.1.2.2 IF Fa1/1 UP
*Sep  6 13:01:26.165: %OER_MC-5-NOTICE: BR 100.1.2.2 IF Fa1/0 UP
*Sep  6 13:01:26.165: %OER_MC-5-NOTICE: BR 100.1.2.2 Active
*Sep  6 13:01:26.165: %OER_MC-5-NOTICE: MC Active
*Sep  6 13:01:26.213: %OER_MC-5-NOTICE: BR 100.1.4.4 UP
*Sep  6 13:01:26.229: %OER_MC-5-NOTICE: BR 100.1.4.4 IF Fa0/1 UP
*Sep  6 13:01:26.257: %OER_MC-5-NOTICE: BR 100.1.4.4 IF Fa0/0 UP
*Sep  6 13:01:26.257: %OER_MC-5-NOTICE: BR 100.1.4.4 Active
R1#sh oer master bord det
Border           Status   UP/DOWN             AuthFail  Version
100.1.4.4        ACTIVE   UP       00:01:00          0  2.2
Fa0/1           EXTERNAL UP
Fa0/0           INTERNAL UP
External            Capacity      Max BW   BW Used    Load Status          Exit Id
Interface            (kbps)       (kbps)    (kbps)    (%)
---------           --------      ------   ------- ------- ------           ------
Fa0/1           Tx    100000       75000         0       0 UP                    6
Rx                100000         0       0
--------------------------------------------------------------------------------
Border           Status   UP/DOWN             AuthFail  Version
100.1.2.2        ACTIVE   UP       00:01:00          0  2.2
Se0/1/0.1       EXTERNAL UP
Fa1/1           EXTERNAL UP
Fa1/0           INTERNAL UP
External            Capacity      Max BW   BW Used    Load Status          Exit Id
Interface            (kbps)       (kbps)    (kbps)    (%)
---------           --------      ------   ------- ------- ------           ------
Se0/1/0.1       Tx      1544        1158         0       0 UP                    5
Rx                  1544         0       0
Fa1/1           Tx    100000       75000         0       0 UP                    4
Rx                100000         0       0

The master controller knows about the interfaces, their role and even capacity on how much bandwidth is available and currently used (depended on how timers are set).

R2(config-router)#do sh oer border
OER BR 100.1.2.2 ACTIVE, MC 100.1.1.1 UP/DOWN: UP 00:13:55,
Auth Failures: 0
Conn Status: SUCCESS
OER Netflow Status: ENABLED, PORT: 3949
Version: 2.2  MC Version: 2.2
Exits
Se0/1/0.1       EXTERNAL
Fa1/0           INTERNAL
Fa1/1           EXTERNAL
R2(config-router)#
PL-Pod123#4
[Resuming connection 4 to r4 ... ]
*Sep  6
R4(config-router)#do sh oer border
OER BR 100.1.4.4 ACTIVE, MC 100.1.1.1 UP/DOWN: UP 00:04:37,
Auth Failures: 0
Conn Status: SUCCESS
OER Netflow Status: ENABLED, PORT: 3949
Version: 2.2  MC Version: 2.2
Exits
Fa0/0           INTERNAL
Fa0/1           EXTERNAL
R4(config-router)#

Now the master has been configured, the border routers know which interfaces they should monitor and NetFlow is automatically enabled to share the utilization status with the master controller.

Now the PfR setup is done we can start with the cool stuff. In the next part the profile phase will commence.

Stay tuned!

Rick Mur

CCIE2 #21946 (R&S / Service Provider)

Sr. Support Engineer – IPexpert, Inc.

OER/PfR Part 1: Set Up, 3.4 out of 5 based on 10 ratings

Tags: ccie lab, CCIE Mock Lab, CCIE R&S 4.0, CCIE Training, ipexpert