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 each 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

30 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

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 cotroller 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
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 conroller 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 have to configure a minimum and maximum time value and also a step value. By default the minimum timer is 300 seconds, maximum is 3000 seconds and the step value is 300 seconds. This means that the first time the master controller will have 300 seconds to find an exit path, if it is unsuccessful, the next time it will add the step time (300 seconds) so it will have 600 seconds. If it’s still unsuccessful the next time it will take 900 seconds, 1200, 1500 and so on….up to a maximum of 3000 seconds.

The holddown timer tells OER how long a new exit path must be used after it went out of policy before we can look for a new best exit path. We do this to prevent flapping between different exit paths. By default this is 300 seconds and on some routers you can reduce it to 90 seconds.

Here is how to change the backoff and holddown timer:

MC(config)#oer master
MC(config-oer-mc)#holddown 90
MC(config-oer-mc)#backoff 90 180 90

This will change the holddown timer to 90 seconds and the min and max backoff timer to 90 seconds.

That’s all I wanted to share with you for now, I hope these changes will help speed up your OER labs. If you have any questions feel free to ask!