Cisco IOS XR RPL Route Policy: prefix-set Examples

2026年9月7日 LOG admin

Classic IOS route-maps do not exist on IOS XR. Instead, ASR 9000, NCS and 8000 routers use the Route Policy Language (RPL), a more structured way to filter and manipulate BGP routes that is mandatory for eBGP peers - every neighbor needs at least a pass-all style policy before routes flow. RPL is built from named sets (prefix-sets, community-sets, as-path-sets) and route-policies that combine matching conditions with actions such as drop, pass, and set. This guide explains RPL with practical prefix-set examples, including the one behavior that surprises IOS veterans: sequential policies always evaluate the original attribute values, not the values a previous action just set.

Why IOS XR Uses RPL Instead of Route-Maps

RPL is not simply route-maps with new syntax. It is a compiled, typed language with real variables, reusable sub-policies, and explicit pass/drop semantics, and the router validates it before it ever reaches the BGP process. Three consequences matter in day-to-day operations:

A policy must terminate with an explicit result. A route-policy either drops, passes, or falls off the end of the policy. Falling off the end means "drop" — if you write a policy whose only branch is an if ... then ... endif, everything that does not match the condition is silently discarded.
Policies attach to a protocol, not to a line of configuration. The same named policy can be applied inbound on twenty neighbors, and show rpl route-policy <name> references tells you exactly where.
Every eBGP session needs a policy. There is no implicit default. Forget the inbound policy and the session comes up, advertises nothing, and accepts nothing.

RPL Building Blocks: prefix-set and route-policy

A prefix-set is a named collection of prefixes with optional length operators. The following example matches the RFC 1918 private ranges plus a couple of bogons, using le 32 to match the prefix and all of its longer subnets:

prefix-set PFX-MARTIANS
  10.0.0.0/8 le 32,
  172.16.0.0/12 le 32,
  192.168.0.0/16 le 32
end-set

Route-policies consume these sets. A policy to drop anything in the martian set and pass everything else looks like this:

route-policy FILTER-MARTIANS
  if destination in ( PFX-MARTIANS ) then
    drop
  endif
  pass
end-policy

Note the pass after end-policy's matching block has closed. That single line is what makes the policy a usable inbound filter: routes that are not martians reach the fall-through statement and are accepted. Remove it and the router drops the entire table.

prefix-set Operators: eq, ge and le

The letter-suffix operators control how much of the prefix length range is matched, and getting them wrong is the most common RPL mistake after missing terminators.

prefix-set PFX-CUSTOMER-AGG
  10.10.0.0/16 ge 17 le 24,
  10.20.0.0/16 le 16,
  10.30.0.0/24 eq 24,
  10.40.0.0/16
end-set

10.10.0.0/16 ge 17 le 24 matches more-specifics of 10.10.0.0/16 between /17 and /24 — never the /16 itself. Useful when combined with a second entry if you need both.
10.20.0.0/16 le 16 is an explicit way of saying "this exact prefix only", since no length greater than 16 is allowed.
10.30.0.0/24 eq 24 is equivalent to writing the prefix with no operator: with no ge or le, RPL matches the exact length and nothing longer.
10.40.0.0/16 matches 10.40.0.0/16 exactly. If you intended to catch 10.40.0.0/24 you needed le 24 — and a customer leaking a /24 out of a /16 you thought you were dropping is the classic leak this operator prevents.

Sets can also be written inline instead of by name, which keeps short one-off filters readable:

route-policy FILTER-RFC1918
  if destination in ( 10.0.0.0/8 le 32, 172.16.0.0/12 le 32, 192.168.0.0/16 le 32 ) then
    drop
  endif
  drop
end-policy

Inline sets are useful for a quick test but they cannot be referenced elsewhere and they are harder to audit. Once a filter is used by more than one policy, promote it to a named set.

Manipulating Attributes with RPL

RPL actions mirror route-map set clauses: set local-preference, set med, set origin, and set community. The if/elseif structure reads naturally:

route-policy SET-PREFS
  if destination in ( PFX-CUSTOMER ) then
    set local-preference 200
    set med 100
  else
    set local-preference 90
  endif
end-policy

An important gotcha: RPL evaluates every condition against the ORIGINAL values of the route. In the example below, a route whose MED was originally 100 is dropped - even though the first action set its MED to 200 - because the second condition is evaluated on the original MED of 100:

route-policy ORIGINAL-VALUES
  if med eq 100 then
    set med 200
  endif
  if med eq 200 then
    drop
  endif
end-policy

The other attribute actions you will use constantly behave the same way. set community with the additive keyword appends to the existing community list instead of replacing it; delete community in ( ... ) strips specific values; prepend as-path and replace as-path rewrite the path; and set next-hop is the strict form that fails if the next hop cannot legally be applied, while sethop always succeeds. In a well-formed policy for an eBGP peer you normally want the strict form so a mistake surfaces during commit rather than silently disappearing.

Community-Sets, AS-Path-Sets and Reusable Policies

Real policies combine several sets, and RPL lets you build a library and reuse it with apply.

community-set COMM-CUSTOMER
  65000:100,
  65000:200,
  65000:999
end-set

as-path-set AS-CUSTOMER
  ios-regex '_65001_',
  ios-regex '_65002_'
end-set

prefix-set PFX-CUSTOMER
  203.0.113.0/24,
  198.51.100.0/24
end-set

route-policy MARK-CUSTOMER
  if community matches-any ( COMM-CUSTOMER ) then
    set local-preference 200
  elseif as-path in ( AS-CUSTOMER ) then
    set local-preference 150
  elseif destination in ( PFX-CUSTOMER ) then
    set local-preference 120
  else
    set local-preference 90
  endif
end-policy

route-policy CUSTOMER-IN
  apply MARK-CUSTOMER
  if destination in ( PFX-MARTIANS ) then
    drop
  endif
  pass
end-policy

Three details worth calling out. matches-any returns true if at least one community in the set is present; matches-every requires all of them. AS-path sets use Cisco IOS regular expressions, which is why the underscore anchors appear on both sides of the AS number. And an apply followed by more conditions is perfectly legal — the sub-policy runs to completion and evaluation continues in the caller, which is how you stack a shared "set local preference" block under a per-customer filter.

Policies can also be parameterized, so the same body serves many customers without duplication:

route-policy SET-LP ($cust, $lp)
  if community matches-any ($cust:$lp) then
    set local-preference $lp
  endif
end-policy

route-policy CUST-217
  apply SET-LP (217, 200)
  pass
end-policy

Applying an RPL Policy to a BGP Neighbor

Policies attach per neighbor and address family with the route-policy command, replacing IOS route-map inbound/outbound keywords:

router bgp 65000
  neighbor 10.0.0.2
    remote-as 65001
    address-family ipv4 unicast
      route-policy FILTER-MARTIANS in
      route-policy ANNOUNCE-CUSTOMER out
    !
  !
!

For a router with dozens of peers, attach the policy to a neighbor-group or session-group instead and inherit it, so a change is made in one place rather than twenty:

router bgp 65000
  neighbor-group CUSTOMER-PEERS
    remote-as 65001
    address-family ipv4 unicast
      route-policy FILTER-MARTIANS in
      route-policy ANNOUNCE-CUSTOMER out
    !
  !
  neighbor 10.0.0.2
    use neighbor-group CUSTOMER-PEERS
  !
  neighbor 10.0.0.3
    use neighbor-group CUSTOMER-PEERS
  !
!

Editing and Verifying Route Policies

Re-entering a route-policy in configuration mode wipes the existing policy body, so keep your RPL in a text file and paste the full policy when you edit. Verify with the BGP show commands:

RP/0/0/CPU0:router# show running-config route-policy
RP/0/0/CPU0:router# show bgp neighbors 10.0.0.2
RP/0/0/CPU0:router# show bgp ipv4 unicast

The dedicated show rpl family is where you actually debug a policy. Unlike show running-config, it prints the policy as the compiler sees it, including the sets it references and everything that attaches to it:

RP/0/0/CPU0:router# show rpl route-policy FILTER-MARTIANS
RP/0/0/CPU0:router# show rpl route-policy FILTER-MARTIANS attachpoints
RP/0/0/CPU0:router# show rpl route-policy FILTER-MARTIANS uses
RP/0/0/CPU0:router# show rpl prefix-set PFX-MARTIANS
RP/0/0/CPU0:router# show rpl prefix-set PFX-MARTIANS references
RP/0/0/CPU0:router# show rpl unused route-policy
RP/0/0/CPU0:router# show rpl maximum

attachpoints lists every neighbor and address family where the policy is bound — the fastest way to find out why one peer behaves differently from its neighbor-group peers.
references on a set shows which policies consume it, which is what you need before deleting a set that "looks unused".
show rpl unused route-policy finds policies that exist but attach to nothing — usually the residue of a migration.
show rpl maximum shows policy line and set consumption against the platform limit, which matters on boxes with thousands of policy lines.

Because RPL is evaluated at the BGP level rather than the interface level, a policy change takes effect for new best paths immediately, but routes already in the Adj-RIB-In are not re-evaluated until the session is refreshed. Apply a soft clear after changing an inbound policy:

RP/0/0/CPU0:router# clear bgp ipv4 unicast 10.0.0.2 soft in
RP/0/0/CPU0:router# show bgp ipv4 unicast neighbors 10.0.0.2 advertised-routes

If you are editing policies as part of a wider change, take a configuration checkpoint first — see our guide to IOS XR commit replace and rollback for the safe way to undo a bad policy push.

Common RPL Errors and What They Mean

Session comes up but no routes flow. The inbound or outbound policy is missing, or it terminates in an implicit drop. Check with show bgp ipv4 unicast neighbors 10.0.0.2 routes and confirm both directions have an explicit pass.
A policy appears to have no effect after an edit. The route was learned before the change. Soft-clear inbound to force re-evaluation.
Half of a policy vanished. The policy was re-entered in configuration mode and only part of the body was pasted. Always paste the complete policy, terminators included.
Commit fails with a set not found. A referenced set was deleted or misspelled. show rpl prefix-set <name> references on the intended set tells you what the policy expects.
A route that should be dropped is accepted. Almost always an operator problem: /16 without le matches only the /16, not its /24s. Verify the set's membership with a more-specific test entry.
MED or local preference looks wrong downstream. Re-read the policy for the original-values rule. A condition on an attribute that an earlier action already changed is still testing the original.

Frequently Asked Questions

Can I convert an IOS route-map to RPL automatically? There is no supported automated converter. IOS XR does include an RPL editor in some releases (rpl editor) with templates, but a route-map with match/set clauses is best translated by hand into a policy with an explicit final pass or drop.

What happens if a route-policy is empty? An empty policy that contains only end-policy drops everything, because falling off the end of a policy means drop. Use pass explicitly when you mean pass-all.

Do I need both in and out policies on eBGP? Not strictly, but you should have both. Without an outbound policy you advertise everything in the RIB, and without an inbound policy you accept whatever the peer sends.

Is RPL used for anything other than BGP? Yes — OSPF, IS-IS and RIP all use RPL on IOS XR for redistribution, and redistribution without a route-policy on a routing protocol that requires one simply does not happen.

Where does the original-values rule actually matter? Whenever two conditions in the same policy test the same attribute, and whenever you chain a policy after an apply that already modified that attribute.