OER (Optimized Edge Routing) Timers for Labs

One of the annoyances of working with OER (Optimized Edge Routing) in labs is that it is based on timers for different actions. This can be very annoying when you are doing labs since it means you will be staring for minutes (or hours) at your console screen, waiting for OER to take any action.

We can however optimize the OER timers to make it learn and react faster, in this lesson I want to give you an overview of the timers we can change.

First of all, you might want to consider changing the load interval of your external interfaces on the border routers. By default, the load interval is calculated every 5 minutes, which is an eternity when you are doing labs. We can change this to a minimum of 30 seconds like this:

BR(config)#interface serial 0/0
BR(config-if)#load-interval 30

Thirty seconds is the lowest value we can use. Configure it using the load-interval command.

The next step is to take a look at the actual OER timers. For the learning process, there are two important timers:

  • periodic-interval
  • monitor-period

oer learning cycle

The learning process for OER has a periodic-interval and a monitor-period. The periodic-interval is a sleep timer that tells OER how often to start the learning process and how to long to sleep and retain the information that it has learned. By default, this is 2 hours which is way too long for a lab. If you keep it at the default, you might find yourself restarting the OER master controller more often than you wish for.

The monitor-period defines how long we will learn the different traffic flows. By default, this is 5 minutes, but we can reduce it. Simply said…OER will learn for a period and then go back to sleep, wake up after a while to learn again, and so on. This is how we can change these timers:

MC(config)#oer master
MC(config-oer-mc-learn)#periodic-interval 1
MC(config-oer-mc-learn)#monitor-period 1

I will set both timers to 1 minute. This makes it suitable for a lab.

There are two more OER timers that you should adjust:

  • backoff
  • holddown

The backoff timer tells OER that once a traffic flow is out of policy, the master controller will wait for a certain amount of time before it tries to find another exit path. This backoff timer tells the master controller how long to wait, and it increases each time the master controller is unable to find an optimal exit path. We use this backoff timer so the master controller gets more time to find an exit path after each time it is unsuccessful.

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 788 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

573 Sign Ups in the last 30 days

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

Tags: , , ,

Forum Replies

  1. You never really want to set backoff to anything but 90 90. So much so that Cisco chanaged the default timers in 15T to 90 90 because of customer demands. OER can take a long term to converge and when you start looking at things to cut down, the backoff timer is the easiest prey to be target for a change to the running config to optimize convergence to INPOLICY.

  2. Hello,
    I have a question, how are backoff and holddown timers related?
    I mean if holddown is set to 90 sec, but backoff is bigger, 300 sec, there will be a time after 90 sec that holddown is saying dont use the current route because its out of policy however as backoff time dont reach to 300 sec so router doesnt figure out yet an alternative path.
    Maybe its first te holddown timer and then starts backoff timer and when it finish the router change path, so the timers are added.


  3. Hello Ignacio

    Note that the holddown timer is a MINIMUM. This means that if it is set to 90, then for 90 seconds, the new exit MUST be used BEFORE any new alternative exit can be selected. If the 90 seconds are up, and there is not yet any new available exit, the current exit will still be used. It does not go out of policy. In other words, for 90 seconds, the exit is locked in and cannot be changed. After the 90 seconds, it can possibly, but not necessarily, be changed.

    Alternatively, the backoff timer is the amount of time a router will wait after a rout

    ... Continue reading in our forum

Ask a question or join the discussion by visiting our Community Forum