About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
BGP selects and advertises routes according to policy; packet forwarding then depends on the routes actually installed in the forwarding system. Received advertisements alone do not prove the path packets will take. RFC 4271 puts unprocessed advertisements in Adj-RIBs-In, runs a decision process that applies the local Policy Information Base, and puts the routes it will advertise in Adj-RIBs-Out. Routes that policy marks ineligible never enter the Loc-RIB, which is the set the speaker selected for its own use.
The recovery mistake is to restore the route map and not the lists it matches, or to restore the lists and not the map, and to assume those are the same kind of gap. The FRRouting filter page distinguishes an unspecified prefix filter from a defined list with no matching entry. But that filter result is not automatically the final route-map verdict. When a prefix-list match condition fails, route-map evaluation continues to later entries; a later permit can still accept the route. Removing all match conditions makes the entry match everything, and its permit or deny action then matters.
This article is about restoring those objects together, and about reading what the running speaker still has before you change it. It is not a configuration to paste. Cisco IOS route maps were not opened. Do not treat the FRR sentences as Cisco behaviour. No BGP session was altered.
Why it matters
A policy restore that denies the routes you still need does not look like a routing-protocol failure. The session stays up. The neighbour is still sending the prefixes. They are discarded locally, the Loc-RIB does not select them, and traffic that depended on that path has no selected route from this speaker. If another, less specific route remains, traffic follows that instead, which can be a different network from the one you meant. RFC 4271 has a section on overlapping routes. This article does not restate that algorithm. It says: withdrawing the specific path is not automatically a black hole to nowhere. It is a black hole when nothing else covers the destination, and it is a silent redirect when something else does. Both are failures of the restore. Neither announces itself as "the prefix list was empty".
The other failure is the permit. A list that is not applied does not filter. Prefixes you had spent years denying are eligible again. That is how a restore "fixes" reachability and also advertises a customer route, or accepts a route, that the lost lines existed to stop.
What the protocol keeps separate
RFC 4271 defines three places a route can sit. Adj-RIBs-In holds unprocessed information advertised by peers. The Loc-RIB holds routes the local decision process has selected. Adj-RIBs-Out holds the routes that will be advertised to particular peers, according to policy.
The decision process applies the policies in the local Policy Information Base to the routes in Adj-RIBs-In. Its output is the set that will be advertised, stored in Adj-RIBs-Out according to policy. The process is described as conceptual. An implementation does not have to follow the text step for step, as long as the externally visible behaviour matches.
Preference is a function of a route's own attributes. The RFC says that function shall not use the existence of other routes, the non-existence of other routes, or the attributes of other routes as inputs. Selection then picks the highest preference among the routes that are eligible. A route can be marked ineligible and excluded from the Loc-RIB. Policy that denies a prefix is how a route becomes ineligible. Policy that you failed to restore is how a route that should have been ineligible is not.
Nothing in that model stores your prefix lists for you. The PIB is local. A neighbour does not send you the route map you used to filter them. When the configuration is gone, the advertisements come back, and the local policy does not, unless you put it back.
Prefix lists in the FRR manual
The FRRouting filter page, titled as the latest documentation and showing no release number, says an IP prefix list is the prefix-based filter, with a length range and a sequence number. You add or delete entries at a chosen sequence. If you do not set a sequence number, the number rises by five, and a new unnumbered entry takes the next multiple of five after the numbers already used. Restoring a fragment of a list without the original sequence numbers does not recreate the old order. It creates a new order around whatever entries are already there. Two halves of a list, loaded one after the other without their sequence numbers, are not the list you lost.
The same page states the two defaults that dominate a restore:
If no IP prefix list is specified, it acts as permit.
If an IP prefix list is defined, and no match is found, the default is deny.
Keep three cases separate: an unapplied filter, a configured match that references a missing object, and an existing list whose entries do not match. The filter page’s default sentences do not establish every missing-reference behaviour across protocols and releases. In a route-map, inspect the match result, the entry’s action, subsequent entries and the final default deny. Do not infer permit-all or deny-all merely from the presence of the map’s name.
The manual's syntax permits or denies a prefix, with optional le and ge length bounds. A restored entry with the wrong length bound matches a different set of prefixes from the one you remember, including none of them. No match, on a defined list, is deny. The length bound is part of the entry, not a comment.
Sequence numbers also decide which entry wins when both could match. The page explains automatic numbering because operators insert lines without numbers. A restore tool that sorts or renumbers will change which line is first. On a list, as on the access lists described just above prefix lists on the same page, order is the policy. Take the sequence numbers from the backup. Do not let a reload assign new ones.
Route maps are an ordered policy on top
The route-map page in the same FRR documentation set says a route map filters and applies actions to a route. It is an ordered list of entries. Each entry can match, and can set attributes.
If an entry specifies no matching conditions, it always matches. A restored entry whose match lines were lost, and whose action is deny, matches every route that reaches it and denies them. That is a broader deny than an empty prefix list, and it does not require the prefix list to be wrong. The match clause is simply gone, and the manual says an entry with no match always matches.
If the entry matches and the policy is permit, the set actions run, and processing of the route map finishes by permitting the route, unless an exit action says otherwise. If the entry matches and the policy is deny, processing finishes and the route is denied. The first terminal match decides. Explicit next or goto exit policies can continue evaluation, so lower entries may still matter. Restoring the entries in the wrong order, which is what regenerated sequence numbers do, changes which entry is first.
A call action invokes another route map after the set actions. If the called map returns deny, the route is denied regardless of the caller's permit. A restore that includes the caller and an empty or denying callee denies routes the caller looks willing to permit. The callee is part of the policy. It is easy to leave it out because it is a different name.
One sentence on that page is a restore gap of its own. For a route reflector to apply a route map to reflected routes, the configuration has to include bgp route-reflector allow-outbound-policy in the BGP router. Restoring the route map does not, by this sentence, apply it to routes the reflector is reflecting, unless that setting is restored too. Without that prerequisite, do not assume the intended route-map effects apply to reflected routes. Verify filtering and attribute results for the installed FRR release; the sentence alone is not proof that every reflected route bypasses every outbound filter. The session looks normal.
What to read before you install a backup
Read the policy that is running, if the process is still up, before you replace it. You want, for each neighbour or address family you care about, which route map is applied on the way in and on the way out, every prefix list or other match that map names, every map those entries call, and whether the route-reflector setting above is on. A backup of "the route maps" that does not include the lists, the called maps, and that setting is a partial policy. Loaded alone, a partial policy can fall through unexpectedly, match every route at an entry whose match was lost, or reach the route-map’s default deny. Evaluate the complete control flow.
Compare sequence numbers in the backup with sequence numbers you are about to load. If the backup has them, keep them. If a file was edited by a tool that dropped them, do not load it as if it were the same list.
Decide what "no route" means for each important prefix before you load. If this speaker is the only path, a deny removes the path. If a covering aggregate remains, traffic follows the aggregate. The restore is not safe in the second case either. It is safe only if the path you intended is the path that will be selected, and the prefixes you intended to reject are ineligible. RFC 4271's externally visible behaviour is the routes you advertise and the routes you install. A looking-glass query, or the speaker's own selected-route display, is the check. This article does not name a command to run, because the FRR pages opened here were the filter and route-map pages, not the operational show pages, and nothing was executed.
Apply inbound and outbound as a pair. Inbound policy decides what enters the decision process from a peer. Outbound policy decides what is placed toward a peer. Restoring only the inbound map, because that was the one in the ticket, leaves the advertisements you send on the old outbound policy or on no policy. Adj-RIBs-Out is per peer and according to policy. It is not a mirror of the Loc-RIB.
Validate the intended policy in an isolated, authorised test environment before a coordinated production change. An apparently spare BGP speaker can still advertise routes and affect other systems; do not use production as a disposable test. A policy load is a live change to which routes are eligible. This article will not describe the load command. The FRR pages document the statements. They do not document a transaction you can roll back, and no such transaction was verified.
What not to borrow from other vendors
Cisco prefix lists and route maps are a widely used vocabulary, and they are not this manual. The IOS XE configuration chapter opened for other articles in this series does not describe BGP policy. The defaults above are sentences on the FRR pages. A Cisco router can differ, including in what an empty list does and in how a route reflector treats outbound policy. If the device you are restoring is not FRR, stop and read that vendor's page. Do not translate "default deny if the list exists" onto it because the idea sounds familiar.
The preference function in RFC 4271 does not look at other routes. That restriction concerns the RFC’s degree-of-preference function, not every step in BGP best-path selection. Attribute changes can alter the result across competing eligible routes, and next-hop feasibility and later tie-break rules still matter. Putting a set action back on the wrong entry, or losing a set action because the entry was renumbered, changes the winner without any prefix being denied. Check the selected route, not only the list of permitted prefixes.
Risks and limits
RFC 4271 is January 2006. The RIB definitions and the decision-process rules cited here are from that text. The overlapping-route algorithm was not restated. Implementations may structure the process differently if the external result matches.
The FRR pages are the "latest" documentation and display no release number. A numbered FRR release can differ. The two default sentences, the always-match rule, the call-action deny rule, automatic sequence numbers, and the route-reflector setting are what those pages said when opened on 11 November 2026.
No session was reset, no list was loaded, and no forwarding test was made. "Black hole" in the ordinary sense, a route to nowhere, is not a term RFC 4271 uses for a denied prefix. The accurate statement is that an ineligible route is not selected and not advertised. What the packet does next depends on whether any other selected route covers the destination.
Research and verification
Drafted with AI assistance on 11 November 2026 and independently source-reviewed on 13 November 2026. No equipment was configured, no article commands were executed and no lab behaviour is claimed. This is educational source research, not an approved production recovery procedure.
Sources
- RFC 4271, A Border Gateway Protocol 4 (BGP-4), Y. Rekhter, T. Li, S. Hares, January 2006. https://www.rfc-editor.org/rfc/rfc4271.txt — Adj-RIB-In, Loc-RIB and Adj-RIB-Out; the decision process applying the local Policy Information Base; ineligible routes excluded from the Loc-RIB; the degree-of-preference function not using other routes as inputs. Independently reopened 13 November 2026.
- FRRouting, Filtering, documentation labelled latest, no release number on the page. https://docs.frrouting.org/en/latest/filter.html — IP prefix lists, sequence numbers stepping by five, permit when no list is specified, default deny when a defined list does not match,
leandge. Independently reopened 13 November 2026. - FRRouting, Route Maps, documentation labelled latest, no release number on the page. https://docs.frrouting.org/en/latest/routemap.html — ordered entries; an entry with no match always matches; permit and deny; call action deny overriding the caller;
bgp route-reflector allow-outbound-policyrequired to apply a route map to reflected routes. Independently reopened 13 November 2026.
This article was originally published on .