Posts Tagged ‘self-ping’
Sometimes people need to conditionally advertise routes into BGP table based on time of day. Say, we may want to adversite IGP prefix 18.104.22.168/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 22.214.171.124 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 126.96.36.199 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 188.8.131.52 255.255.255.0 Loopback0 184.108.40.206 tag 100 track 1 ip route 220.127.116.11 255.255.255.0 Loopback0 18.104.22.168 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.