BGP Conditional Advertisement: advertise-map, exist-map, and non-exist-map

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 behaviour 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.

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 neighbour, 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 neighbour:

You use one or the other, never both, on the same neighbour. 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 neighbour 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

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 <tracked-prefix> 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 neighbour 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), which pushes your inbound filter across the session so your neighbour stops sending you routes you were only going to discard. Everything in this cluster hangs off the BGP pillar guide.