BGP Time-Based Policy Routing

 

Sometimes people need to conditionally advertise routes into BGP table based on time of day. Say, we may want to adversite IGP prefix 150.1.1.0/24 with community 1:100 during daytime and with community 1:200 at the other time. Back in days, the procedure was easy - you had to create time based ACL, and use it in route-map to set communities:

time-range DAY 
 periodic daily 9:00 to 18:00access-list 101 permit ip any any time-range DAY 
 
route-map SET_COMMUNITY 10 match ip address 101 
 set community 1:100!route-map SET_COMMUNITY 20 
 set community 1:200

This construct worked fine back in days with 12.2T and 12.3 IOSes up to 12.3(17)T. However, since 12.3(17)T, BGP scanner behavior has changed significally. Up to the new version, redistribution into BGP table was based on BGP scanner periodically polling the IGP routes every scan-interval (one minute by default). With the new IOS code, redistribution is purely event driven: a new route is added/deleted from BGP table based on event, signaled by IGP (e.g. IGP route withdrawn, next-hop change etc). This change in BGP scanner behavior was not clearly documented, unlike the related BGP support for next-hop address tracking feature. Ovbsiously, a change in time-range is not treated as an IGP event, hence the filter does not work anymore.

Still,there is a number of workarounds. Here is one of them: we use time-based ACL to filter or permit ICMP packets, and advertise routers based on that virtual “reachability” info.

First,we create time-range and time-based access-list:

time-range DAY 
 periodic daily 9:00 to 18:00!access-list 101 permit ip any any time-range DAY 

Nextwe create a special loopback interface, which is used send ICMP echo packets to “ourself” and attach the ACL to the interface to filter incoming (looped back) packets:

interface Loopback0 
 ip address 150.1.1.1 255.255.255.255 ip access-group 101 in 

Wecreate a new IP SLA monitor, to send ICMP echo packets over loopback interface. If the time-based ACL permit pings, the monitor state will be “reachable”

ip sla monitor 1 
 type echo protocol ipIcmpEcho 150.1.1.1 timeout 100 
 frequency 1

Next we track our “pinger” state. The first tracker is “on” when the loopback is “open” by packet filter, the second one is active when the time-based ACL filters packets:

track 1 rtr 1 reachability 
! 
! Inverse logic!track 2 list boolean and 
 object 1 not

The we create two static routes, bound to the mentioned trackets. That is, the static route with tag 100 is only active when loopback is “open”, i.e. time-based ACL permits packets. The other static route is active only when time-range is inactive (the second tracker tells that the destination is “reachable”):

ip route 150.1.1.0 255.255.255.0 Loopback0 150.1.1.254 tag 100 track 1 
ip route 150.1.1.0 255.255.255.0 Loopback0 150.1.1.253 tag 200 track 2

Now we redistribute static routes into BGP, based on tag values, and also set communities based on the tags:

router bgp 1 
 redistribute static route-map STATIC_TO_BGP!route-map STATIC_TO_BGP permit 10 
 match tag 100 set community 1:100 
! 
route-map STATIC_TO_BGP permit 20 match tag 200 
 set community 1:200

This is also a funny example of how you can tie up together multiple IOS features at the same time.

ShareThis