Cisco IOS XR Routing Policy Language (RPL) Guide

RPL is where IOS XR stops looking like IOS. Instead of route-maps with implicit sequence matching, XR uses named, structured policy blocks with typed sets, explicit accept or drop semantics and parameterised reusable sub-policies. The payoff is policy that reads like code and can be validated before it is attached to a session. This guide covers the building blocks - prefix-sets, as-path-sets, community-sets and route-policy blocks - the actions that decide a route's fate, and the operational habits that keep complex filters debuggable.

Sets first, policy second

prefix-set CUSTOMER-V4
  203.0.113.0/24 le 28,
  198.51.100.0/24
end-set

as-path-set TRANSIT-ASNS
  ios-regex '_64512_',
  ios-regex '_64513_'
end-set

community-set NO-EXPORT
  no-export
end-set

Sets are named and referenced by policy, which means a prefix list can be updated once and every policy that uses it inherits the change. The classic IOS regex rules apply in ios-regex, but XR also supports a stricter as-path-set expression syntax that is easier to reason about in reviews.

Build the policy

route-policy CUST-IN
  if destination in CUSTOMER-V4 then
    if community matches-any NO-EXPORT then
      drop
    else
      set local-preference 150
      set community (65001:100) additive
      pass
    endif
  else
    drop
  endif
end-policy

Three semantic details deserve attention. First, a policy that ends without an explicit action drops the route - explicit terminal handling prevents surprises in reviews. Second, additive appends to existing communities rather than replacing them, which is what you want when downstream operators rely on their own tags. Third, conditionals nest, so keep policies shallow and factor complexity into sub-policies.

Reuse with parameters and apply

route-policy SET-LP($lp)
  set local-preference $lp
  pass
end-policy

route-policy CUSTOMER-IN
  if destination in CUSTOMER-V4 then
    apply SET-LP(200)
  else
    drop
  endif
end-policy

router bgp 65001
 neighbor 203.0.113.1
  address-family ipv4 unicast
   route-policy CUSTOMER-IN in

Parameterised policies turn a copy-paste repository into a small library: one policy sets local preference, another tags communities, a third performs prefix-length filtering. Larger deployments stand up a policy server and consolidate to a single policy entry point per session, which makes an audit possible.

Testing before you commit

show rpl route-policy CUSTOMER-IN detail
show rpl route-policy CUSTOMER-IN inactive
show bgp ipv4 unicast 203.0.113.0/24
show bgp ipv4 unicast neighbors 203.0.113.1 advertised-routes

show rpl ... inactive lists defined-but-unused policies, which is the fastest way to spot a policy that was replaced but never cleaned up. To reason about a policy's effect, check a route's attributes before and after applying it, and inspect the advertised-routes view to confirm what you are actually sending to a peer - inbound policy bugs are seen from the neighbour's perspective.

Operational habits

• Name policies with a direction suffix (-IN, -OUT) so an accidental cross-attachment is obvious.
• Comment each policy with its intent and the ticket or standard it implements; XR allows comments inside policy sets.
• Roll changes with commit confirmed so a policy that blackholes traffic reverts automatically - see Junos commit confirmed for the same pattern on another platform.
• Test with a lab session before attaching to production BGP. Related reading: IOS XR segment routing with OSPF prefix-SID.

原文链接：https://community.cisco.com/t5/service-providers-knowledge-base/asr9000-xr-understanding-and-using-rpl-route-policy-language/ta-p/3117050