[c-nsp] BGP Next hop tracking / 'hold down' route...

[Drew Weaver]

Hello all, I've been having a bit of an issue and I refuse to believe that nobody else has seen this or solved it before =)

This route exists as a hold down to announce to border/edge routers for eBGP:

ip route 192.168.0.0 255.255.224.0 Null0 192.0.2.1 199 tag 50

192.168.25.1 peers with 192.168.25.7 for iBGP, 192.168.25.1 knows 192.168.25.7/32 via OSPF:

Routing entry for 192.168.25.7/32
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1000

When the physical connection between 192.168.25.1 and 192.168.25.7 is severed:

Jun 24 10:46:38 EDT: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.25.7 on TenGigabitEthernet3/5 from FULL to DOWN, Neighbor Down: BFD node down
RTR#sh ip route 192.168.25.7
Routing entry for 192.168.0.0/19, supernet
  Known via "static", distance 199, metric 0
  Tag 50
  Redistributing via ospf 1, bgp 65535
  Advertised by bgp 65535 route-map STATIC-TO-BGP
  Routing Descriptor Blocks:
  * 192.0.2.1, via Null0
      Route metric is 0, traffic share count is 1
      Route tag 50

RTR#sh ip cef 192.168.25.7
192.168.0.0/19
  nexthop 192.0.2.1 Null0

The problem is, once the /32 no longer exists in OSPF the router tries to use the less specific 192.168.0.0/19 route to communicate with 192.168.25.7 until the BGP session *finally* closes which in this day and age may as well be an eternity.

Questions:

1) 192.0.2.1 routes to Null0 and the static route also points to Null0 as it's interface, should IOS really be using something that recurses to Null0 as a BGP next-hop or is this a bug? Is there any way to configure IOS not to do this?
2) Is selective next-hop tracking event driven? Meaning if I enable it while the /32 is in IGP and the above scenario takes place, will it prevent this scenario from blackholing traffic while waiting for the BGP hold timer to expire?

I am also open to any other suggestions.

Thank you all so much =)
-Drew