Cisco – 2 BGP Upstreams, One sending default route, another Full Table

If I understand the question correctly you have an IGP (or local) route to the network, and you annouce it over BGP. When the route vanishes in the IGP (or local) you want BGP to pull the route.

If that is the case you are doing stuff wrong(TM), and Quagga will not let you easily do this. From the manual for the network command:

BGP: network A.B.C.D/M

    This command adds the announcement network.             

    router bgp 1
     network 10.0.0.0/8

    This configuration example says that network 10.0.0.0/8 will be announced 
    to all neighbors. Some vendors' routers don't advertise routes if they 
    aren't present in their IGP routing tables; bgp doesn't care about IGP 
    routes when announcing its routes. 

This is due to the increased flapping you can easily get if you export IGP information in BGP. We have enough of a route churn on the internet allready, and it's considered bad practice to redistribute routing information from IGP into BGP. BGP is not an IGP, and don't abuse it as one ;)

Also I can't really see any good cases for pulling the route from the Internet (it will cause flapping and you risk getting dampened for hours or days), unless you are ending up in a split-AS situation if this specific route is gone and want to protect yourself from the weird routing issues this can cause. (In this case, you should consider if you want the router to stay online at all. Split-AS situations are nasty!)

The correct solution(TM) is to leave the route up and as stable as possible, regardless of what your IGP is doing. If you lose the connection to the network just drop the traffic locally. Make sure you don't loop it back to your transit provider if the IGP route to the network is down.

The basic rule is "never change your BGP announcements unless it's something the whole Internet has to know about". That your IGP is flapping is not something the rest of the Internet cares about.

Edit:

From what I understand your network looks like this:

Provider (AS 5555) --------------------- Provider (AS 5555)
 (12.12.12.12)                                   |
     | eBGP                                      |eBGP
     |                                           |
  Router1---------15.15.15.0/24---------------Router2
172.16.14.1                                 172.16.14.2
     |                  iBGP                     |
      --------------------------------------------

And your problem is that if you take down the interface on Router1 towards 15.15.15.0/24 you want it to stop announcing the network so you shift the data over to 172.16.14.2. This type of automatic changes to your peering policy is not something you usually do, and is as far as I know not something supported by Quagga. Instead you are expected to reroute the data over the IGP and keep your peerings static. If you were to do changes to your peerings you would change the MED (MULTI_EXIT_DISC) to steer the traffic to the right router.

Note that if taking down 15.15.15.0/24 splits your AS you have additional failure modes, none of them good.

Add a static route with a next hop that goes to peer 2 only because of a route to peer 2. That way, so long as you are receiving that route, the static route will point to peer 2. But the second you lose that route, your existing failover will flip it.

Pick any route that goes to peer 2 but that will go away if you cannot reach peer 2. Then add a static route for the traffic you want to cover with a next hop covered by the route you picked. That will cause traffic that matches the second route to track the first route.

For example, say the prefix you want to control traffic to is 216.152.32.0/24. You craft a static route to 216.152.32.0/24 and you choose its next hop. Since it's a static route, traffic to 216.152.32.0/24 will be routed towards that next hop (assuming there's no more-specific route, which there won't be). So that reduces the problem to choosing an appropriate next hop.

You want the traffic to go one way when the link to peer 2 is up and the other way when that link isn't working. So you need to pick a next hop that has that property. In principle, any IP inside a route you dynamically receive from peer 2 will work. That traffic will go to peer 2 when you have that route and will follow your default to peer 1 when you don't. (Assuming your default is properly set up to failover.)

Ideally, pick a route that's "core" to peer 2, but not too close to your point of connection. You want it to be "core" to peer 2 because you don't want it to flip over to peer 1 ever. You don't want it too close to you because if your node gets isolate, you want to fail over the peer 2. If you do a traceroute to a few random sites, you may be able to find a core router in a nearby city, on their backbone. That will do.