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.
To get a better picture of what happens, you can do a show file systems | i flash|nvram, dir nvram:, and dir flash: on some of the devices in question. The short answer: NVRAM is a kind of flash memory, and it is never removable. The location of vlan.dat varies by switching platform... the IOS configfiles are always in nvram unless the device is forced to manually store them elsewhere.
Catalyst 6500
Router#show file systems | i nvram|flash
65536000 32514632 flash rw sup-bootflash:
129004 127128 nvram rw const_nvram:
1964024 1960900 nvram rw nvram:
65536000 32514632 flash rw bootflash:
15990784 15990784 flash rw dfc#3-bootflash:
Router#dir const_nvram:
Directory of const_nvram:/
1 -rw- 1876 <no date> vlan.dat
129004 bytes total (127128 bytes free)
Router#dir nvram:
Directory of nvram:/
1918 -rw- 0 <no date> startup-config
1919 ---- 0 <no date> private-config
1920 -rw- 0 <no date> underlying-config
1 ---- 4 <no date> rf_cold_starts
2 ---- 47 <no date> persistent-data
3 -rw- 0 <no date> ifIndex-table
1964024 bytes total (1960900 bytes free)
Router#show ver | i IOS
IOS (tm) s72033_rp Software (s72033_rp-IPSERVICES_WAN-M), Version 12.2(18)SXF16, RELEASE SOFTWARE (fc2)
Router#
Catalyst 3560
DAL-EDG-SW01#sh ver | i IOS
Cisco IOS Software, C3560 Software (C3560-IPSERVICESK9-M), Version 12.2(55)SE, RELEASE SOFTWARE (fc2)
DAL-EDG-SW01#show file systems | i nvram|flash
File Systems:
Size(b) Free(b) Type Flags Prefixes
* 32514048 8593920 flash rw flash:
524288 488396 nvram rw nvram:
DAL-EDG-SW01#
DAL-EDG-SW01#dir nvram:
Directory of nvram:/
479 -rw- 29740 <no date> startup-config
480 ---- 3028 <no date> private-config
1 ---- 35 <no date> persistent-data
2 -rw- 0 <no date> ifIndex-table
3 -rw- 598 <no date> IOS-Self-Sig#3434.cer
524288 bytes total (488396 bytes free)
DAL-EDG-SW01#dir flash:
Directory of flash:/
2 -rwx 11190304 Mar 1 1993 12:44:55 -05:00 c3560-ipbasek9-mz.122-53.SE1.bin
3 -rwx 12677496 Oct 6 2010 20:11:22 -04:00 c3560-ipservicesk9-mz.122-55.SE.bin
4 -rwx 13336 Feb 28 1993 19:01:18 -05:00 vlan.dat
6 -rwx 3096 Apr 29 2011 15:21:40 -04:00 multiple-fs
7 -rwx 3028 Apr 29 2011 15:21:40 -04:00 private-config.text
8 -rwx 29740 Apr 29 2011 15:21:40 -04:00 config.text
32514048 bytes total (8593920 bytes free)
DAL-EDG-SW01#
Catalyst 3550
TQ-DC5-CORE1#sh file systems | i nvram|flash
* 15998976 7844352 flash rw flash:
15998976 7844352 unknown rw zflash:
393216 377552 nvram rw nvram:
TQ-DC5-CORE1#dir flash:
Directory of flash:/
2 -rwx 5 Mar 13 2011 08:13:56 -04:00 private-config.text
3 -rwx 8127303 Feb 28 1993 19:18:13 -05:00 c3550-ipservices-mz.122-44.SE6.bin
4 -rwx 320 Feb 28 1993 19:19:52 -05:00 system_env_vars
5 -rwx 255 Feb 28 1993 19:34:51 -05:00 info
6 -rwx 255 Feb 28 1993 19:37:38 -05:00 info.ver
7 -rwx 0 Feb 28 1993 19:19:52 -05:00 env_vars
10 -rwx 6736 Oct 29 2010 16:24:23 -04:00 vlan.dat
9 -rwx 1048 Mar 13 2011 08:13:56 -04:00 multiple-fs
11 -rwx 14583 Mar 13 2011 08:13:56 -04:00 config.text
15998976 bytes total (7844352 bytes free)
TQ-DC5-CORE1#dir nvram:
Directory of nvram:/
378 -rw- 14583 <no date> startup-config
379 ---- 5 <no date> private-config
1 -rw- 0 <no date> ifIndex-table
393216 bytes total (377552 bytes free)
TQ-DC5-CORE1#sh ver | i IOS
Cisco IOS Software, C3550 Software (C3550-IPSERVICES-M), Version 12.2(44)SE6, RELEASE SOFTWARE (fc1)
TQ-DC5-CORE1#
Best Answer
Issue the shutdown first, then issue the "no keepalive" command, then bring the interface back up. It should show up/up at this point and hold that state indefinitely (for a GE, anyhow). Turning keepalive tracking off while the interface has already marked itself down isn't going to bring it up.