blog
    BGP Time-Based Policy Rou ...
    25 January 08

    BGP Time-Based Policy Routing

    Posted byPetr Lapukhov
    facebooktwitterlinkedin
    news-featured

    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.

    Hey! Don’t miss anything - subscribe to our newsletter!

    © 2022 INE. All Rights Reserved. All logos, trademarks and registered trademarks are the property of their respective owners.
    instagram Logofacebook Logotwitter Logolinkedin Logoyoutube Logo