RoutingGlobal Config

route-policy [name]

Defines or modifies a route policy, which is used to control routing information (e.g., BGP attributes, redistribution) based on match conditions and set actions.

Overview

The 'route-policy' command in Cisco IOS-XR is used to create a named policy that can be applied to routing protocols (BGP, OSPF, ISIS, etc.) to control route advertisement, redistribution, and attribute manipulation. Route policies are a fundamental part of IOS-XR's routing architecture, replacing the route-maps used in classic IOS. They provide a flexible, programmatic way to match routes based on various criteria (prefix, community, AS-path, etc.) and set attributes (local preference, metric, community, etc.). Policies are written in a text-based language similar to a scripting language, with if-then-else constructs, loops, and nested conditions. They are applied in the routing protocol configuration using the 'route-policy' keyword (e.g., 'neighbor 10.0.0.1 route-policy SET-LP in'). Understanding route policies is crucial for controlling traffic engineering, implementing BGP path selection, and managing route redistribution. In troubleshooting, route policies can be verified using 'show route-policy' and 'show bgp policy' to see how routes are affected.

Syntax·Global Config

route-policy [name] [parameter1 parameter2 ...]

When to Use This Command

Filtering BGP routes from a specific neighbor based on community values.
Setting local preference for routes received from a customer.
Redistributing OSPF routes into BGP with a specific metric.
Modifying AS-path prepend for outbound BGP advertisements.

Parameters

Parameter	Syntax	Required	Description
name	WORD	Required	The name of the route policy. Must be unique and can contain letters, numbers, and hyphens.
parameter	WORD	Optional	Optional parameters that can be passed to the policy when applied. They are referenced as $param in the policy body.

Command Examples

Basic route policy to set local preference

route-policy SET-LP
  set local-preference 200
end-policy

The policy is defined but produces no output until applied. The 'end-policy' statement terminates the policy definition.

Route policy with match condition

route-policy MATCH-COMMUNITY
  if community matches-any (100:100) then
    set local-preference 150
  else
    pass
  endif
end-policy

This policy checks if the route has community 100:100; if so, sets local preference to 150; otherwise, passes the route unchanged.

Understanding the Output

The 'route-policy' command itself does not produce output; it enters a subconfiguration mode where policy statements are entered. The policy is stored in the running configuration. To view the policy, use 'show running-config route-policy [name]' or 'show route-policy [name]'. The output shows the policy statements in a structured format. Each line represents a condition or action. 'if' and 'endif' denote conditional blocks. 'pass' means the route is accepted without modification. 'drop' means the route is rejected. 'set' modifies attributes. 'community' and 'extcommunity' are used for BGP communities. 'match' conditions can include prefix-list, community, as-path, etc. A healthy policy has clear logic without contradictions. Problematic policies may have missing 'endif' or incorrect nesting.

Configuration Scenarios

BGP inbound policy to set local preference based on community

An ISP wants to prefer routes from a customer that advertise a specific community.

Topology

ISP-Router --- Customer-Router (AS 65001)

Steps

1.Define a community-set to match the customer's community.
2.Create a route policy that matches the community and sets local preference.
3.Apply the policy inbound on the BGP neighbor.

Configuration

!
community-set CUSTOMER-COMM
  100:100
end-set
!
route-policy SET-LP
  if community matches-any CUSTOMER-COMM then
    set local-preference 200
  else
    set local-preference 100
  endif
end-policy
!
router bgp 65000
  neighbor 10.0.0.2
    address-family ipv4 unicast
      route-policy SET-LP in
!

Verify: Use 'show bgp neighbors 10.0.0.2 received routes' to verify local preference is set.

Watch out: Ensure the community-set is defined before the route policy, otherwise the policy will fail to reference it.

Troubleshooting with This Command

When troubleshooting route policies on IOS-XR, start by verifying the policy is correctly applied using 'show running-config router bgp' or 'show bgp neighbors <neighbor> policy'. Use 'show route-policy <name>' to display the policy logic. To see how a specific route is affected, use 'show bgp <prefix> bestpath' or 'show route <prefix> detail' to check attributes. If routes are not being accepted, check for 'drop' statements or missing 'pass'. Use 'debug route-policy' to trace policy evaluation (caution: can be verbose). Common issues include incorrect community matching (case-sensitive), missing 'end-policy', or applying the policy in the wrong direction (in vs out). Also verify that the policy references exist (e.g., prefix-list, community-set).

CCNA Exam Tips

Remember that route policies are evaluated in order; the first match wins.

Know the difference between 'pass' (continue to next policy) and 'done' (stop processing).

Be able to interpret a route policy configuration and determine what it does to a given route.

Common Mistakes

Forgetting to end the policy with 'end-policy' - causes syntax error.

Using 'set' without a matching 'if' condition when one is intended - policy may not work as expected.

Misunderstanding 'pass' vs 'done' - 'pass' continues to next policy in sequence, 'done' stops evaluation.

Platform Notes

Cisco IOS-XR route policies are more powerful than classic IOS route-maps. They support nested if-then-else, loops, and parameterization. Unlike IOS, IOS-XR uses 'end-policy' to terminate the policy. The 'community-set' and 'extcommunity-set' are separate objects. In IOS, route-maps use 'match ip address prefix-list' and 'set community'. IOS-XR also supports 'apply' to call other policies. Version differences: In earlier XR versions (e.g., 4.x), route policy syntax was slightly different; newer versions (6.x+) support more advanced constructs like 'when' and 'if' with 'and/or'. Always check the specific version documentation.

Practice for the CCNA 200-301

Test your knowledge with hundreds of CCNA practice questions covering all exam domains.

Practice CCNA Questions