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:00 access-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
Next we 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
We create 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.
About Petr Lapukhov, 4xCCIE/CCDE:
Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.
Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website
You can leave a response, or trackback from your own site.
One Response to “BGP Time-Based Policy Routing”
Leave a Reply


Hi Petr
this is really an interesting solution, though (or just because :0) ) it is quite complicated!
Is there a special reason, why you put the
static routes like this?
ip route 150.1.1.0 255.255.255.0 Loopback0 150.1.1.254
(Interface, and IP Address)
best regards
Matthias