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
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
MC(config-oer-mc-learn)#periodic-interval 1
MC(config-oer-mc-learn)#monitor-period 1I 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.
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.
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.
Thanks
Regards
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