> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # BGP Conditional Advertisement: advertise-map, exist-map, and non-exist-map - URL: https://www.pinglabz.com/bgp-conditional-advertisement/ - Published: 2026-07-12T06:32:01.000Z - Updated: 2026-08-24T09:42:53.000Z - Description: BGP conditional advertisement withholds a prefix until a condition you define is no longer true. Walk through advertise-map, exist-map, and non-exist-map on Cisco IOS XE to keep a backup path truly idle. - Author: Jaime - Tags: BGP, Labs, CCIE, #Import 2026-08-01 19:54 Every dual-homed network eventually asks the same question: how do I keep a backup path *truly* idle until I need it? Local preference and AS-path prepending only change which path is *preferred*. The backup prefix is still out there, still in the global table, still attracting traffic if someone upstream has a different policy. Conditional advertisement is the answer: it withholds a prefix entirely until a condition you define is no longer true. This is a core CCIE Enterprise Infrastructure skill and one of the few BGP features where the configuration reads almost like English but the behavior surprises people. This article walks through `advertise-map`, `exist-map`, and `non-exist-map` on Cisco IOS XE, with real output from a six-router CML lab. If you need the fundamentals first, start with the [complete BGP guide](https://www.pinglabz.com/bgp/). ## The problem conditional advertisement solves Picture an enterprise, AS 65001, dual-homed to two providers. ISP-A is the primary transit: fast, cheap, well-peered. ISP-B is a backup circuit that bills by the megabit. You have a prefix, 172.16.1.0/24, that you only want reachable over ISP-B if ISP-A is gone. The usual tools all fail here in the same way: - **AS-path prepending toward ISP-B** makes the path less attractive, but it does not make it invisible. Any network closer to ISP-B than to ISP-A still comes in that way. - **Setting a low local preference** only affects your own inbound path selection. It says nothing about how the internet reaches you. - **Communities like no-export** stop propagation past your neighbor, which is often too blunt. What you actually want is: *do not advertise 172.16.1.0/24 to ISP-B at all, unless ISP-A has failed*. That is conditional advertisement. ## How it works: two route-maps, one decision Conditional advertisement attaches two route-maps to a neighbor: advertise-map The prefixes whose advertisement you want to control. Match them with a prefix-list. These prefixes are advertised *only* when the condition is satisfied. non-exist-map The tracked prefix. While it **is present** in the BGP table, the advertise-map prefixes are withheld. When it **disappears**, they are advertised. This is the backup-path pattern. exist-map The mirror image. While the tracked prefix **is present**, the advertise-map prefixes are advertised. When it disappears, they are withdrawn. Used for "only advertise X if I can still reach Y". You use one or the other, never both, on the same neighbor. The overwhelmingly common case is `non-exist-map`, because the overwhelmingly common requirement is a backup path. ### The tracked prefix must be a real signal This is where most designs go wrong. The prefix you track in the non-exist-map must be something that **only exists while the primary path is healthy**. If you track a prefix that you can also learn through the backup provider, the condition never clears and your backup never activates. In the lab below, AS 65001 tracks 100.100.100.0/24, which is originated by ISP-A itself and is not reachable through ISP-B. When the ISP-A links go down, that prefix leaves the AS 65001 BGP table completely, and the condition fires. If instead we had tracked a customer prefix from a distant AS reachable through both providers, the condition would never have been met. ## The lab Six IOL-XE routers on Cisco Modeling Labs. AS 65001 is R1 and R2 (iBGP over OSPF). R1 is dual-attached to ISP-A (AS 100, routers R3 and R4). R2 is the ISP-B edge, peering with R5 in AS 200\. AS 300 (R6) sits beyond both providers. R1 originates 172.16.1.0/24 (the backup prefix) and carries it to R2 over iBGP. R2 owns the eBGP session to ISP-B, so R2 is where the conditional advertisement lives. ### Baseline: everything is advertised Before any policy, R2 hands ISP-B the full set of AS 65001 prefixes, including the backup: ``` R2#show ip bgp neighbors 10.0.25.2 advertised-routes Network Next Hop Metric LocPrf Weight Path r>i 1.1.1.1/32 1.1.1.1 0 100 0 i *>i 10.10.10.0/24 1.1.1.1 0 100 0 i *>i 10.10.10.66/32 1.1.1.1 0 100 0 i *>i 10.30.30.0/24 1.1.1.1 0 100 0 i *>i 100.100.100.0/24 1.1.1.1 0 200 0 100 i *>i 172.16.1.0/24 1.1.1.1 0 100 0 i Total number of prefixes 6 ``` That 172.16.1.0/24 at the bottom is the problem. ISP-B is announcing it to the world right now. ## Configuration ``` ! The prefix we want to control ip prefix-list BACKUP-PFX seq 5 permit 172.16.1.0/24 ! The prefix that proves ISP-A is alive ip prefix-list PRIMARY-WATCH seq 5 permit 100.100.100.0/24 route-map ADV-BACKUP permit 10 match ip address prefix-list BACKUP-PFX route-map TRACK-PRIMARY permit 10 match ip address prefix-list PRIMARY-WATCH router bgp 65001 address-family ipv4 neighbor 10.0.25.2 advertise-map ADV-BACKUP non-exist-map TRACK-PRIMARY ``` Read it out loud and it is exactly the requirement: *advertise the routes matched by ADV-BACKUP, but only when the routes matched by TRACK-PRIMARY do not exist.* ## Verification: the steady state The status field on the neighbor is the single most useful command here. It tells you what the router has actually decided: ``` R2#show ip bgp neighbors 10.0.25.2 | include Condition-map Condition-map TRACK-PRIMARY, Advertise-map ADV-BACKUP, status: Withdraw ``` `status: Withdraw` means the tracked prefix exists, so the backup is being held back. And the advertised-routes list confirms it - five prefixes now, and 172.16.1.0/24 is not among them: ``` R2#show ip bgp neighbors 10.0.25.2 advertised-routes Network Next Hop Metric LocPrf Weight Path r>i 1.1.1.1/32 1.1.1.1 0 100 0 i *>i 10.10.10.0/24 1.1.1.1 0 100 0 i *>i 10.10.10.66/32 1.1.1.1 0 100 0 i *>i 10.30.30.0/24 1.1.1.1 0 100 0 i *>i 100.100.100.0/24 1.1.1.1 0 200 0 100 i Total number of prefixes 5 ``` Note what conditional advertisement did *not* do: everything else is still advertised normally. The advertise-map only governs the prefixes it matches. Everything outside it follows your ordinary outbound policy. ## Verification: the failover Now shut both of R1's links to ISP-A. 100.100.100.0/24 leaves the AS 65001 BGP table entirely: ``` R2#show ip bgp | include 100.100|172.16|Network Network Next Hop Metric LocPrf Weight Path *>i 172.16.1.0/24 1.1.1.1 0 100 0 i ``` Wait about a minute, and the condition flips: ``` R2#show ip bgp neighbors 10.0.25.2 | include Condition-map Condition-map TRACK-PRIMARY, Advertise-map ADV-BACKUP, status: Advertise ``` And ISP-B now has the backup prefix: ``` R5#show ip bgp 172.16.1.0/24 BGP routing table entry for 172.16.1.0/24, version 28 Paths: (1 available, best #1, table default) 65001 10.0.25.1 from 10.0.25.1 (2.2.2.2) Origin IGP, localpref 100, valid, external, best ``` Bring the ISP-A links back, and within a scan cycle the status returns to `Withdraw` and ISP-B stops hearing the prefix. ## The gotcha nobody warns you about: it is not instant Conditional advertisement is evaluated by the BGP scanner, not by the update process. On IOS XE that scan runs on a 60-second interval by default. In the lab above the tracked prefix disappeared immediately, but the status field stayed on `Withdraw` for the better part of a minute before flipping. This matters enormously for design. Conditional advertisement is **not a fast-convergence mechanism**. If your requirement is "traffic must move within 500 ms", conditional advertisement is the wrong tool and you want BFD plus a pre-installed backup path. Conditional advertisement is for policy-level failover measured in tens of seconds: "if the primary transit is genuinely gone, start announcing the DR prefix." You can see the scan interval in `show ip bgp summary` (`scan interval 60 secs`). Tuning it down is possible with `bgp scan-time`, but on a router carrying a real internet table you are trading CPU for convergence, and that trade is rarely worth it. ## exist-map: the other direction Swap `non-exist-map` for `exist-map` and the logic inverts. Now the advertise-map prefixes are announced *while* the tracked prefix is present, and withdrawn when it goes away. The classic use case is a multi-site enterprise where a site's aggregate should only be advertised while that site is actually reachable. Site B's edge router advertises 10.20.0.0/16 to the provider only while it can see a specific host route or loopback inside Site B. Lose the site, stop advertising the aggregate, and traffic naturally shifts to Site A rather than being black-holed at a router that no longer has a path. ``` route-map ADV-SITE-B permit 10 match ip address prefix-list SITE-B-AGGREGATE route-map SITE-B-ALIVE permit 10 match ip address prefix-list SITE-B-CORE-LOOPBACK router bgp 65001 address-family ipv4 neighbor 203.0.113.1 advertise-map ADV-SITE-B exist-map SITE-B-ALIVE ``` ## Conditional advertisement vs the alternatives Conditional advertisement **Controls:** whether the prefix is announced at all **Speed:** up to 60s (scanner) **Use for:** true backup prefixes, DR sites AS-path prepend **Controls:** how attractive the path looks **Speed:** immediate **Use for:** nudging inbound traffic, not hiding a prefix Communities (no-export etc.) **Controls:** how far the prefix propagates **Speed:** immediate **Use for:** scope limits, provider-signalled policy Outbound prefix-list **Controls:** whether the prefix is announced at all **Speed:** static - no failover **Use for:** permanent filtering, not conditional behavior ## Troubleshooting checklist 1. **Status stuck on Withdraw when the primary is down?** Your tracked prefix is still in the BGP table. Run `show ip bgp ` and look at where it came from. Nine times out of ten it is arriving through the backup provider, which defeats the whole design. 2. **Status flipped to Advertise but the neighbor still does not have the prefix?** Check that the prefix is actually in your BGP table and is a best path. Conditional advertisement can only announce something you have. 3. **Nothing at all being advertised?** Confirm the advertise-map route-map has a matching permit clause. A route-map with a `match` that never matches falls through to the implicit deny, and you get an empty advertisement set. 4. **It works but takes too long?** That is the 60-second scanner, and it is by design. See above. 5. **Condition flapping?** Track a stable prefix. A tracked prefix that itself flaps will drive your backup announcement in and out of the global table, which is much worse than never having configured it. ## Key takeaways - Conditional advertisement is the only BGP mechanism that decides *whether* a prefix is announced based on live routing state. - `non-exist-map` is the backup-path pattern: withhold the prefix while the tracked route exists, advertise it when the tracked route disappears. `exist-map` is the mirror image. - The tracked prefix must be uniquely reachable through the primary path. If the backup provider can also deliver it, your condition will never fire. - `show ip bgp neighbors x.x.x.x | include Condition-map` gives you the router's own verdict: `status: Withdraw` or `status: Advertise`. Start every troubleshoot there. - It is evaluated by the BGP scanner, so expect up to 60 seconds of lag. It is a policy mechanism, not a convergence mechanism. Next in the expert BGP series: [Outbound Route Filtering (ORF)](https://www.pinglabz.com/bgp-outbound-route-filtering-orf/), which pushes your inbound filter across the session so your neighbor stops sending you routes you were only going to discard. Everything in this cluster hangs off the [BGP pillar guide](https://www.pinglabz.com/bgp/).