Time-Based Static Routes

Before someone accuses me of being totally FCoE/DCB-focused, here’s an interesting EEM trick. Damian wanted to have time-dependent static routes to ensure expensive backup path is only established during the working hours. I told him to use cron with EEM to modify router configuration (and obviously lost him in the acronym forest)... but there’s an even better solution: use reliable static routing and modify just the track object’s state with EEM.

Static route first: we’ll create a floating default route (we’re solving the backup path problem) tied to a track object.

ip route Tunnel 0 250 track 42

Next, we have to create the track object itself. We’ll create a stub-object since it won’t track an IP SLA or interface state; we just need a flag that we’ll set with EEM. We also have to decide what happens after a router reload. It might be a good idea to have the backup path available, so the default state of the track object should be up.

track 42 stub-object
 default-state up

Last step: create two EEM applets. One of them will set the track object’s state to down at the end of the business day, the other one will set it to up in the morning.

event manager applet DisableBackup
 event timer cron name DisableBackup cron-entry "0 17 * * *"
 action 1.0 track set 42 state down
event manager applet EnableBackup
 event timer cron name EnableBackup cron-entry "0 8 * * 1-5"
 action 1.0 track set 42 state up

You might wonder why you should use this slightly convoluted solution when you could simply modify the router configuration in EEM applets. The answer is simple: if your EEM applets are modifying the configuration, you never know whether you should save configuration changes before reloading the router… and if you use a configuration monitoring tool, you might get lots of unnecessary alerts.

More information

Related solutions:


  1. A concern that I would have with this configuration is what would happen if the box reloads between 17:01 and 07:59. The default state would mean that the route would be up. As the EEM is event-basedd, no event would be triggered until the next morning. Routing will then happen over the tunnel during a time frame where it shouldn't. Something like this might be a more robust solution:

    access-list 100 permit ip any any time-range time1
    route-map default permit 10
    match ip address 100
    set interface Tunnel0
    time-range time1
    periodic daily 8:00 to 17:00
    interface FastEthernet0/0
    ip policy route-map default
  2. The Policy based solution is real cool.


  3. The policy based solution seems to be sending ALL traffic to the Tunnel during the time range ignoring the primary route that may be available during this time.

    The original problem, if you see in the post is, "to use the BACKUP expensive route during working hours only".
  4. can be done on a dynamic configuration of EEM
Add comment