The policy language provides two kinds of persistent, namable objects: sets and policies. Definition of these objects is bracketed by beginning and ending command lines. For example, to define a policy named test, the configuration syntax would look similar to the following:

  route-policy test
  [ . . . policy statements . . . ]
  end-policy
  
  

Legal names for policy objects can be any sequence of the upper- and lowercase alphabetic characters; the numerals 0 to 9; and the punctuation characters period, hyphen, and underscore. A name must begin with a letter or numeral.

In this context, the term set is used in its mathematical sense to mean an unordered collection of unique elements. The policy language provides sets as a container for groups of values for matching purposes. Sets are used in conditional expressions. The elements of the set are separated by commas. Null (empty) sets are allowed.

In the following example:

  prefix-set backup-routes 
    # currently no backup routes are defined 
  end-set
  
  

a condition such as:

  if destination in backup-routes then 
  
  

evaluates as FALSE for every route, because there is no match-condition in the prefix set that it satisfies.

Five kinds of sets exist: as-path-set, community-set, extcommunity-set, prefix-set, and rd-set. You may want to perform comparisons against a small number of elements, such as two or three community values, for example. To allow for these comparisons, the user can enumerate these values directly. These enumerations are referred to as inline sets. Functionally, inline sets are equivalent to named sets, but allow for simple tests to be inline. Thus, comparisons do not require that a separate named set be maintained when only one or two elements are being compared. See the set types described in the following sections for the syntax. In general, the syntax for an inline set is a comma-separated list surrounded by parentheses as follows: (element-entry , element-entry , element-entry, ...element-entry), where element-entry is an entry of an item appropriate to the type of usage such as a prefix or a community value.

The following is an example using an inline community set:

  route-policy sample-inline
  if community matches-any ([10..15]:100) then
  set local-preference 100
  endif
  end-policy
  
  

The following is an equivalent example using the named set test-communities:

  community-set test-communities
  10:100,
  11:100,
  12:100,
  13:100,
  14:100,
  15:100
  end-set
  
  route-policy sample
  if community matches-any test-communities then
  set local-preference 100
  endif
  end-policy
  
  

Both of these policies are functionally equivalent, but the inline form does not require the configuration of the community set just to store the six values. You can choose the form appropriate to the configuration context. In the following sections, examples of both the named set version and the inline form are provided where appropriate.

An AS path set comprises operations for matching an AS path attribute. The only matching operation is a regular expression match.

Named Set Form

The named set form uses the ios-regex keyword to indicate the type of regular expression and requires single quotation marks around the regular expression.

The following is a sample definition of a named AS path set:

  as-path-set aset1
  ios-regex ’_42$’,
  ios-regex ’_127$’
  end-set
  
  

This AS path set comprises two elements. When used in a matching operation, this AS path set matches any route whose AS path ends with either the autonomous system (AS) number 42 or 127.

To remove the named AS path set, use the no as-path-set aset1 command-line interface (CLI) command.

Note

Regular expression matching is CPU intensive. The policy performance can be substantially improved by either collapsing the regular expression patterns together to reduce the total number of regular expression invocations or by using equivalent native as-path match operations such as ‘as-path neighbor-is’, ‘as-path originates-from’ or ‘as-path passes-through’.

  (ios-regex '_42$', ios-regex '_127$')
  
  

A community-set holds community values for matching against the BGP community attribute. A community is a 32-bit quantity. Integer community values must be split in half and expressed as two unsigned decimal integers in the range from 0 to 65535, separated by a colon. Single 32-bit community values are not allowed. The following is the named set form:

  community-set cset1
  12:34,
  12:56,
  12:78,
  internet
  end-set
  

  (12:34, 12:56, 12:78)
  ($as:34, $as:$tag1, 12:78, internet)
  
  

  community-set cset3
     123:*
  end-set
  
  

A prefix-set holds IPv4 or IPv6 prefix match specifications, each of which has four parts: an address, a mask length, a minimum matching length, and a maximum matching length. The address is required, but the other three parts are optional. The address is a standard dotted-decimal IPv4 or colon-separated hexadecimal IPv6 address. The mask length, if present, is a nonnegative decimal integer in the range from 0 to 32 (0 to 128 for IPv6) following the address and separated from it by a slash. The optional minimum matching length follows the address and optional mask length and is expressed as the keyword ge (mnemonic for greater than or equal to), followed by a nonnegative decimal integer in the range from 0 to 32 (0 to 128 for IPv6). The optional maximum matching length follows the rest and is expressed by the keyword le (mnemonic for less than or equal to), followed by yet another nonnegative decimal integer in the range from 0 to 32 (0 to 128 for IPv6). A syntactic shortcut for specifying an exact length for prefixes to match is the eq keyword (mnemonic for equal to).

If a prefix match specification has no mask length, then the default mask length is 32 for IPv4 and 128 for IPv6. The default minimum matching length is the mask length. If a minimum matching length is specified, then the default maximum matching length is 32 for IPv4 and 128 for IPv6. Otherwise, if neither minimum nor maximum is specified, the default maximum is the mask length.

Radix trie lookup is used to perform prefix-set matching.

The prefix-set itself is a comma-separated list of prefix match specifications. The following are examples:

  prefix-set legal-ipv4-prefix-examples
     10.0.1.1,
     10.0.2.0/24,
     10.0.3.0/24 ge 28,
     10.0.4.0/24 le 28,
     10.0.5.0/24 ge 26 le 30,
     10.0.6.0/24 eq 28,
     10.0.7.2/32 ge 16 le 24,
     10.0.8.0/26 ge 8 le 16
  end-set
  
  prefix-set legal-ipv6-prefix-examples
    2001:0:0:1::/64,
    2001:0:0:2::/64 ge 96,
    2001:0:0:2::/64 ge 96 le 100,
    2001:0:0:2::/64 eq 100
  end-set
  
  

The first element of the prefix-set matches only one possible value, 10.0.1.1/32 or the host address 10.0.1.1. The second element matches only one possible value, 10.0.2.0/24. The third element matches a range of prefix values, from 10.0.3.0/28 to 10.0.3.255/32. The fourth element matches a range of values, from 10.0.4.0/24 to 10.0.4.240/28. The fifth element matches prefixes in the range from 10.0.5.0/26 to 10.0.5.252/30. The sixth element matches any prefix of length 28 in the range from 10.0.6.0/28 through 10.0.6.240/28. The seventh element matches any prefix of length 32 in the range 10.0.[0..255].2/32 (from 10.0.0.2/32 to 10.0.255.2). The eighth element matches any prefix of length 26 in the range 10.[0..255].8.0/26 (from 10.0.8.0/26 to 10.255.8.0/26).

The following prefix-set consists entirely of invalid prefix match specifications:

  prefix-set ILLEGAL-PREFIX-EXAMPLES
     10.1.1.1 ge 16,
     10.1.2.1 le 16,
     10.1.3.0/24 le 23,
     10.1.4.0/24 ge 33,
     10.1.5.0/25 ge 29 le 28
  end-set
  
  

Neither the minimum length nor maximum length is valid without a mask length. For IPv4, the minimum length must be less than 32, the maximum length of an IPv4 prefix. For IPv6, the minimum length must be less than 128, the maximum length of an IPv6 prefix. The maximum length must be equal to or greater than the minimum length.

An rd-set is used to create a set with route distinguisher (RD) elements. An RD set is a 64-bit value prepended to an IPv4 address to create a globally unique Border Gateway Protocol (BGP) VPN IPv4 address.

You can define RD values with the following commands:

• a.b.c.d:m:*—BGP VPN RD in IPv4 format with a wildcard character. For example, 10.0.0.2:255.255.0.0:*.

• a.b.c.d/m:n—BGP VPN RD in IPv4 format with a mask. For example, 10.0.0.2:255.255.0.0:666.

• a.b.c.d:** —BGP VPN RD in IPv4 format with a wildcard character. For example, 10.0.0.2:255.255.0.0.

• a.b.c.d:n— BGP VPN RD in IPv4 format. For example, 10.0.0.2:666.

• asn:*— BGP VPN RD in ASN format with a wildcard character. For example, 10002:255.255.0.0.

• asn:n—BGP VPN RD in ASN format. For example, 10002:666.

The following is an example of an rd-set:

  rd-set rdset1
     10.0.0.0/8:*,
     10.0.0.0/8:777,
     10.0.0.0:*,
     10.0.0.0:777,
     65000:*,
     65000:777
  end-set
  
  

As policies are being defined, some simple verifications, such as range checking of values, is done. For example, the MED that is being set is checked to verify that it is in a proper range for the MED attribute. However, this range checking cannot cover parameter specifications because they may not have defined values yet. These parameter specifications are verified when a policy is attached to an attach point. The policy repository also verifies that there are no recursive definitions of policy, and that parameter numbers are correct. At attach time, all policies must be well formed. All sets and policies that they reference must be defined and have valid values. Likewise, any parameter values must also be in the proper ranges.

As long as a given policy is not attached at an attach point, the policy is allowed to refer to nonexistent sets and policies, which allows for freedom of workflow. You can build configurations that reference sets or policy blocks that are not yet defined, and then can later fill in those undefined policies and sets, thereby achieving much greater flexibility in policy definition. Every piece of policy you want to reference while defining a policy need not exist in the configuration. Thus, a user can define a policy sample that references the policy bar using an apply statement even if the policy bar does not exist. Similarly, a user can enter a policy statement that refers to a nonexistent set.

However, the existence of all referenced policies and sets is enforced when a policy is attached. If you attempt to attach the policy sample with the reference to an undefined policy bar at an inbound BGP policy using the neighbor 1.2.3.4 address-family ipv4 unicast policy sample in command, the configuration attempt is rejected because the policy bar does not exist.

Likewise, you cannot remove a route policy or set that is currently in use at an attach point because this removal would result in an undefined reference. An attempt to remove a route policy or set that is currently in use results in an error message to the user.

A condition exists that is referred to as a null policy in which the policy bar exists but has no statements, actions, or dispositions in it. In other words, the policy bar does exist as follows:

  route-policy bar
  end-policy
  
  

This is a valid policy block. It effectively forces all routes to be dropped because it is a policy block that never modifies a route, nor does it include the pass statement. Thus, the default action of drop for the policy block is followed.

Policies that are in use do, on occasion, need to be modified. Traditionally, configuration changes are done by completely removing the relevant configuration and then re-entering it. However, this allows for a window of time in which no policy is attached and the default action takes place. RPL provides a mechanism for an atomic change so that if a policy is redeclared, or edited using a text editor, the new configuration is applied immediately—which allows for policies that are in use to be changed without having a window of time in which no policy is applied at the given attach point.

The policy repository knows which attributes, actions, and comparisons are valid at each attach point. When a policy is attached, these actions and comparisons are verified against the capabilities of that particular attach point. Take, for example, the following policy definition:

  route-policy bad
  set med 100
  set level level-1-2
  set ospf-metric 200
  end-policy
  
  

This policy attempts to perform actions to set the BGP attribute med, IS-IS attribute level, and OSPF attribute cost. The system allows you to define such a policy, but it does not allow you to attach such a policy. If you had defined the policy bad and then attempted to attach it as an inbound BGP policy using the BGP configuration statement neighbor 1.2.3.4 address-family ipv4 unicast route-policy bad in the system would reject this configuration attempt. This rejection results from the verification process checking the policy and realizing that while BGP could set the MED, it has no way of setting the level or cost as the level and cost are attributes of IS-IS and OSPF, respectively. Instead of silently omitting the actions that cannot be done, the system generates an error to the user. Likewise, a valid policy in use at an attach point cannot be modified in such a way as to introduce an attempt to modify a nonexistent attribute or to compare against a nonexistent attribute. The verifiers test for nonexistent attributes and reject such a configuration attempt.

The additional-path attach point provides increased control based on various attribute match operations. This attach point is used to decide whether a route-policy should be used to select additional-paths for a BGP speaker to be able to send multiple paths for the prefix.

The add path enables BGP prefix independent convergence (PIC) at the edge routers.

router bgp 100
 address-family ipv4 unicast
 additional-paths selection route-policy add-path-policy

The dampening attach point controls the default route-dampening behavior within BGP. Unless overridden by a more specific policy on the associate peer, all routes in BGP apply the associated policy to set their dampening attributes.

The following policy sets dampening values for BGP IPv4 unicast routes. Those routes that are more specific than a /25 take longer to recover after they are dampened than the routes that are less specific than /25.

Note

When the dampening policy runs for a route, then the last "set dampening" statement that is encountered, takes effect. If a "drop" statement is encountered, then the route is not dampened; even if the "set dampening" statement is encountered. If a "pass" or "done" statement is encountered but not the "set dampening" statement, then the route is dampened using the default dampening parameters. For example: When policy1 applies another policy that is called policy2 and if a "pass" statement is encountered in policy2, then policy2 exits and continues to execute policy1. If a "done" statement is encountered in policy2, then both policy1 and policy2 exits immediately.

  route-policy sample_damp
    if destination in (0.0.0.0/0 ge 25) then
      set dampening halflife 30 others default
    else
      set dampening halflife 20 others default
    endif
  end-policy
  
  router bgp 2
    address-family ipv4 unicast
      bgp dampening route-policy sample_damp
      .
      .
      .
  

The default originate attach point allows the default route (0.0.0.0/0) to be conditionally generated and advertised to a peer, based on the presence of other routes. It accomplishes this configuration by evaluating the associated policy against routes in the Routing Information Base (RIB). If any routes pass the policy, the default route is generated and sent to the relevant peer.

The following policy generates and sends a default-route to the BGP neighbor 10.0.0.1 if any routes that match 10.0.0.0/8 ge 8 le 32 are present in the RIB.

  route-policy sample-originate
    if rib-has-route in (10.0.0.0/8 ge 8 le 32) then
       pass
    endif
  end-policy
  
  router bgp 2
    neighbor 10.0.0.1
      remote-as 3
      address-family ipv4 unicast
      default-originate route-policy sample-originate
      .
      .
      .
  

The neighbor export attach point selects the BGP routes to send to a given peer or group of peers. The routes are selected by running the set of possible BGP routes through the associated policy. Any routes that pass the policy are then sent as updates to the peer or group of peers. The routes that are sent may have had their BGP attributes altered by the policy that has been applied.

The following policy sends all BGP routes to neighbor 10.0.0.5. Routes that are tagged with any community in the range 2:100 to 2:200 are sent with a MED of 100 and a community of 2:666. The rest of the routes are sent with a MED of 200 and a community of 2:200.

  route-policy sample-export
    if community matches-any (2:[100-200]) then
      set med 100
      set community (2:666)
    else
      set med 200
      set community (2:200)
    endif
  end-policy
  
  router bgp 2
    neighbor 10.0.0.5
      remote-as 3
    address-family ipv4 unicast
      route-policy sample-export out
      .
      .
      .
  

The neighbor import attach point controls the reception of routes from a specific peer. All routes that are received by a peer are run through the attached policy. Any routes that pass the attached policy are passed to the BGP Routing Information Base (BRIB) as possible candidates for selection as best path routes.

When a BGP import policy is modified, it is necessary to rerun all the routes that have been received from that peer against the new policy. The modified policy may now discard routes that were previously allowed through, allow through previously discarded routes, or change the way the routes are modified. A new configuration option in BGP (bgp auto-policy-soft-reset) that allows this modification to happen automatically in cases for which either soft reconfiguration is configured or the BGP route-refresh capability has been negotiated.

The following example shows how to receive routes from neighbor 10.0.0.1. Any routes received with the community 3:100 have their local preference set to 100 and their community tag set to 2:666. All other routes received from this peer have their local preference set to 200 and their community tag set to 2:200.

  route-policy sample_import
    if community matches-any (3:100) then
      set local-preference 100
      set community (2:666)
    else
      set local-preference 200
      set community (2:200)
    endif
  end-policy
  
  router bgp 2
    neighbor 10.0.0.1
      remote-as 3
      address-family ipv4 unicast
        route-policy sample_import in
        .
        .
        .
  

The network attach point controls the injection of routes from the RIB into BGP. A route policy attached at this point is able to set any of the valid BGP attributes on the routes that are being injected.

The following example shows a route policy attached at the network attach point that sets the well-known community no-export for any routes more specific than /24:

  route-policy NetworkControl
    if destination in (0.0.0.0/0 ge 25) then
      set community (no-export) additive
    endif
  end-policy
  
  router bgp 2
    address-family ipv4 unicast
      network 172.16.0.5/27 route-policy NetworkControl
  

The redistribute attach point within OSPF injects routes from other routing protocol sources into the OSPF link-state database, which is done by selecting the routes it wants to import from each protocol. It then sets the OSPF parameters of cost and metric type. The policy can control how the routes are injected into OSPF by using the set metric-type or set ospf-metric command.

The following example shows how to redistribute routes from IS-IS instance instance_10 into OSPF instance 1 using the policy OSPF-redist. The policy sets the metric type to type-2 for all redistributed routes. IS-IS routes with a tag of 10 have their cost set to 100, and IS-IS routes with a tag of 20 have their OSPF cost set to 200. Any IS-IS routes not carrying a tag of either 10 or 20 are not be redistributed into the OSPF link-state database.

  route-policy OSPF-redist
    set metric-type type-2
    if tag eq 10 then
      set ospf cost 100
    elseif tag eq 20 then
      set ospf cost 200
    else
      drop
    endif
  end-policy
  router ospf 1
    redistribute isis instance_10 policy OSPF-redist
    .
    .
    .
  

The show bgp attach point allows the user to display selected BGP routes that pass the given policy. Any routes that are not dropped by the attached policy are displayed in a manner similar to the output of the show bgp command.

In the following example, the show bgp route-policy command is used to display any BGP routes carrying a MED of 5:

  route-policy sample-display
    if med eq 5 then
      pass
    endif
  end-policy
  !
  show bgp route-policy sample-display
  
  

A show bgp policy route-policy command also exists, which runs all routes in the RIB past the named policy as if the RIB were an outbound BGP policy. This command then displays what each route looked like before it was modified and after it was modified, as shown in the following example:

  show rpl route-policy test2
  
  route-policy test2
    if (destination in  (10.0.0.0/8 ge 8 le 32)) then
      set med 333
    endif
  end-policy
  !

  show bgp
  
  BGP router identifier 10.0.0.1, local AS number 2
  BGP main routing table version 11
  BGP scan interval 60 secs
  Status codes:s suppressed, d damped, h history, * valid, > best
                i - internal, S stale
  Origin codes:i - IGP, e - EGP, ? - incomplete
     Network            Next Hop            Metric LocPrf Weight Path
  *> 10.0.0.0           10.0.1.2                10             0 3 ?
  *> 10.0.0.0/9         10.0.1.2                10             0 3 ?
  *> 10.0.0.0/10        10.0.1.2                10             0 3 ?
  *> 10.0.0.0/11        10.0.1.2                10             0 3 ?
  *> 10.1.0.0/16        10.0.1.2                10             0 3 ?
  *> 10.3.30.0/24       10.0.1.2                10             0 3 ?
  *> 10.3.30.128/25     10.0.1.2                10             0 3 ?
  *> 10.128.0.0/9       10.0.1.2                10             0 3 ?
  *> 10.255.0.0/24      10.0.101.2            1000    555      0 100 e
  *> 10.255.64.0/24     10.0.101.2            1000    555      0 100 e
  ....
  
  
show bgp policy route-policy test2
  
  10.0.0.0/8 is advertised to 10.0.101.2
  
    Path info:
      neighbor:10.0.1.2        neighbor router id:10.0.1.2
      valid  external  best  
    Attributes after inbound policy was applied:
      next hop:10.0.1.2
      MET ORG AS 
      origin:incomplete  neighbor as:3  metric:10  
      aspath:3
    Attributes after outbound policy was applied:
      next hop:10.0.1.2
      MET ORG AS 
      origin:incomplete  neighbor as:3  metric:333  
      aspath:2 3
  ...
  

The table policy feature in BGP allows you to configure traffic index values on routes as they are installed in the global routing table. This feature is enabled using the table-policy command and supports the BGP policy accounting feature.

BGP policy accounting uses traffic indices that are set on BGP routes to track various counters. See the Implementing Routing Policy on Cisco IOS XR Software module in the Routing Configuration Guide for Cisco NCS 6000 Series Routers for details on table policy use. See the Cisco Express Forwarding Commands on Cisco IOS XR Software module in the IP Addresses and Services Command Reference for Cisco NCS 6000 Series Routers for details on BGP policy accounting.

Table policy also provides the ability to drop routes from the RIB based on match criteria. This feature can be useful in certain applications and should be used with caution as it can easily create a routing ‘black hole’ where BGP advertises routes to neighbors that BGP does not install in its global routing table and forwarding table.

The import attach point provides control over the import of routes from the global VPN IPv4 table to a particular VPN routing and forwarding (VRF) instance.

For Layer 3 VPN networks, provider edge (PE) routers learn of VPN IPv4 routes through the Multiprotocol Internal Border Gateway Protocol (MP-iBGP) from other PE routers and automatically filters out route announcements that do not contain route targets that match any import route targets of its VRFs.

This automatic route filtering happens without RPL configuration; however, to provide more control over the import of routes in a VRF, you can configure a VRF import policy.

The following example shows how to perform matches based on a route target extended community and then sets the next hop. If the route has route target value 10:91, then the next hop is set to 172.16.0.1. If the route has route target value 11:92, then the next hop is set to 172.16.0.2. If the route has Site-of-Origin (SoO) value 10:111111 or 10:111222, then the route is dropped. All other non-matching routes are dropped.

  route-policy bgpvrf_import
    if extcommunity rt matches-any (10:91) then
      set next-hop 172.16.0.1
    elseif extcommunity rt matches-every (11:92) then
      set next-hop 172.16.0.2
    elseif extcommunity soo matches-any (10:111111, 10:111222) then
      pass
    endif
  end-policy
  
  vrf vrf_import
   address-family ipv4 unicast
  import route-policy bgpvrf_import
  

The export attach point provides control over the export of routes from a particular VRF to a global VPN IPv4 table.

For Layer 3 VPN networks, export route targets are added to the VPN IPv4 routes when VRF IPv4 routes are converted into VPN IPv4 routes and advertised through the MP-iBGP to other PE routers (or flow from one VRF to another within a PE router).

A set of export route targets is configured with the VRF without RPL configuration; however, to set route targets conditionally, you can configure a VRF export policy.

The following example shows some match and set operations supported for the export route policy. If a route matches 172.16.1.0/24 then the route target extended community is set to 10:101, and the weight is set to 211. If the route does not match 172.16.1.0/24 but the origin of the route is egp, then the local preference is set to 212 and the route target extended community is set to 10:101. If the route does not match those specified criteria, then the route target extended community 10:111222 is added to the route. In addition, RT 10:111222 is added to the route that matches any of the previous conditions as well.

  route-policy bgpvrf_export
    if destination in (172.16.1.0/24) then
      set extcommunity rt (10:101)
      set weight 211
    elseif origin is egp then
      set local-preference 212
      set extcommunity rt (10:101)
    endif
    set extcommunity rt (10:111222) additive
  end-policy
  
  vrf vrf-export
    address-family ipv4 unicast
      export route-policy bgpvrf-export
      .
      .
      .
  

The allocate-label attach point provides increased control based on various attribute match operations. This attach point is typically used in inter-AS option C to decide whether the label should be allocated or not when sending updates to the neighbor for the IPv4 labeled unicast address family. The attribute setting actions supported are for pass and drop.

The retain route target attach point within BGP allows the specification of match criteria based only on route target extended community. The attach point is useful at the route reflector (RR) or at the Autonomous System Boundary Router (ASBR).

Typically, an RR has to retain all IPv4 VPN routes to peer with its PE routers. These PEs might require routers tagged with different route target IPv4 VPN routes resulting in non-scalable RRs. You can achieve scalability if you configure an RR to retain routes with a defined set of route target extended communities, and a specific set of VPNs to service.

Another reason to use this attach point is for an ASBR. ASBRs do not require that VRFs be configured, but need this configuration to retain the IPv4 VPN prefix information.

The following example shows how to configure the route policy retainer and apply it to the retain route target attach point. The route is accepted if the route contains route target extended communities 10:615, 10:6150, and 15.15.15.15.15:15. All other non-matching routes are dropped.

  extcommunity-set rt rtset1
    0:615, 
    10:6150, 
    15.15.15.15.15:15
    end-set
  
  route-policy retainer
    if extcommunity rt matches-any rtset1 then
      pass
    endif
  end-policy
  
  router bgp 2
    address-family vpnv4 unicast
      retain route-target route-policy retainer
      .
      .
      .
  

The neighbor-orf attach point provides the filtering of incoming BGP route updates using only prefix-based matching. In addition to using this as an inbound filter, the prefixes and disposition (drop or pass) are sent to upstream neighbors as an Outbound Route Filter (ORF) to allow them to perform filtering.

The following example shows how to configure a route policy orf-preset and apply it to the neighbor ORF attach point. The prefix of the route is dropped if it matches any prefix specified in orf-preset (172.16.1.0/24, 172.16.5.0/24, 172.16.11.0/24). In addition to this inbound filtering, BGP also sends these prefix entries to the upstream neighbor with a permit or deny so that the neighbor can filter updates before sending them on to their destination.

  prefix-set orf-preset
    172.16.1.0/24,
    172.16.5.0/24,
    172.16.11.0/24
  end-set
  
  route-policy policy-orf
    if orf prefix in orf-preset then
      drop
    endif
    if orf prefix in (172.16.3.0/24, 172.16.7.0/24, 172.16.13.0/24) then
      pass
    endif
  
  router bgp 2
    neighbor 1.1.1.1
      remote-as 3
      address-family ipv4 unicast
        orf route-policy policy-orf
      .
      .
      .
  

The next-hop attach point provides increased control based on protocol and prefix-based match operations. The attach point is typically used to decide whether to act on a next-hop notification (up or down) event.

Support for next-hop tracking allows BGP to monitor reachability for routes in the Routing Information Base (RIB) that can directly affect BGP prefixes. The route policy at the BGP next-hop attach point helps limit notifications delivered to BGP for specific prefixes. The route policy is applied on RIB routes. Typically, route policies are used in conjunction with next-hop tracking to monitor non-BGP routes.

The following example shows how to configure the BGP next-hop tracking feature using a route policy to monitor static or connected routes with the prefix 10.0.0.0 and prefix length 8.

  route-policy nxthp_policy_A
    if destination in (10.0.0.0/8) and protocol in (static, connected) then
      pass
    endif
  end-policy
  
  router bgp 2
    address-family ipv4 unicast
      nexthop route-policy nxthp_policy_A
        .
        .
        .
  

The clear-policy attach point provides increased control based on various AS path match operations when using a clear bgp command. This attach point is typically used to decide whether to clear BGP flap statistics based on AS-path-based match operations.

The following example shows how to configure a route policy where the in operator evaluates to true if one or more of the regular expression matches in the set my-as-set successfully match the AS path associated with the route. If it is a match, then the clear command clears the associated flap statistics.

  as-path-set my-as-set
    ios-regex '_12$',
    ios-regex '_13$'
  end-set
  
  route-policy policy_a
    if as-path in my-as-set then
      pass
    else
      drop
    endif
  end-policy
  
  clear bgp ipv4 unicast flap-statistics route-policy policy_a
  

The debug attach point provides increased control based on prefix-based match operations. This attach point is typically used to filter debug output for various BGP commands based on the prefix of the route.

The following example shows how to configure a route policy that will only pass the prefix 20.0.0.0 with prefix length 8; therefore, the debug output shows up only for that prefix.

  route-policy policy_b
    if destination in (10.0.0.0/8) then
      pass
    else
      drop
  
    endif
  end-policy
  
  debug bgp update policy_b
  

This table summarizes the BGP attributes and operators per attach points.

Some BGP route attributes are inaccessible from some BGP attach points for various reasons. For example, the set med igp-cost only command makes sense when there is a configured igp-cost to provide a source value.

The default-information originate attach point allows the user to conditionally inject the default route 0.0.0.0/0 into the OSPF link-state database, which is done by evaluating the attached policy. If any routes in the local RIB pass the policy, then the default route is inserted into the link-state database.

The following example shows how to generate a default route if any of the routes that match 10.0.0.0/8 ge 8 le 25 are present in the RIB:

  route-policy ospf-originate
    if rib-has-route in (10.0.0.0/8 ge 8 le 25) then
      pass
    endif
  end-policy
  
  router ospf 1
    default-information originate policy ospf-originate
    .
    .
    .
  

Border Gateway Protocol (BGP) routers receive multiple paths to the same destination. As a standard, by default the BGP best path algorithm decides the best path to install in IP routing table. This is used for traffic forwarding.

BGP assigns the first valid path as the current best path. It then compares the best path with the next in the list. This process continues, until BGP reaches the end of the list of valid paths. This contains all rules used to determine the best path. When there are multiple paths for a given address prefix, BGP:

• Selects one of the paths as the best path as per the best-path selection rules.

• Installs the best path in its forwarding table. Each BGP speaker advertises only the best-path to its peers.

Note	The advertisement rule of sending only the best path does not convey the full routing state of a destination, present on a BGP speaker to its peers.

After the BGP speaker receives a path from one of its peers; the path is used by the peer for forwarding packets. All other peers receive the same path from this peer. This leads to a consistent routing in a BGP network. To improve the link bandwidth utilization, most BGP implementations choose additional paths satisfy certain conditions, as multi-path, and install them in the forwarding table. Incoming packets for such are load-balanced across the best-path and the multi-path(s). You can install the paths in the forwarding table that are not advertised to the peers. The RR route reflector finds out the best-path and multi-path. This way the route reflector uses different communities for best-path and multi-path. This feature allows BGP to signal the local decision done by RR or Border Router. With this new feature, selected by RR using community-string (if is-best-path then community 100:100). The controller checks which best path is sent to all R's. Border Gateway Protocol routers receive multiple paths to the same destination. While carrying out best path computation there will be one best path, sometimes equal and few non-equal paths. Thus, the requirement for a best-path and is-equal-best-path.

The BGP best path algorithm decides the best path in the IP routing table and used for forwarding traffic. This enhancement within the RPL allows creating policy to take decisions. Adding community-string for local selection of best path. With introduction of BGP Additional Path (Add Path), BGP now signals more than the best Path. BGP can signal the best path and the entire path equivalent to the best path. This is in accordance to the BGP multi-path rules and all backup paths.

The default-information originate attach point allows the user to conditionally inject the default route 0.0.0.0/0 into the OSPF link-state database, which is done by evaluating the attached policy. If any routes in the local RIB pass the policy, then the default route is inserted into the link-state database.

The following example shows how to generate a default route if any of the routes that match 10.0.0.0/8 ge 8 le 25 are present in the RIB:

  route-policy ospf-originate
    if rib-has-route in (10.0.0.0/8 ge 8 le 25) then
      pass
    endif
  end-policy
  
  router ospf 1
    default-information originate policy ospf-originate
    .
    .
    .
  

The redistribute attach point within OSPF injects routes from other routing protocol sources into the OSPF link-state database, which is done by selecting the routes it wants to import from each protocol. It then sets the OSPF parameters of cost and metric type. The policy can control how the routes are injected into OSPF by using the set metric-type or set ospf-metric command.

The following example shows how to redistribute routes from IS-IS instance instance_10 into OSPF instance 1 using the policy OSPF-redist. The policy sets the metric type to type-2 for all redistributed routes. IS-IS routes with a tag of 10 have their cost set to 100, and IS-IS routes with a tag of 20 have their OSPF cost set to 200. Any IS-IS routes not carrying a tag of either 10 or 20 are not be redistributed into the OSPF link-state database.

  route-policy OSPF-redist
    set metric-type type-2
    if tag eq 10 then
      set ospf cost 100
    elseif tag eq 20 then
      set ospf cost 200
    else
      drop
    endif
  end-policy
  router ospf 1
    redistribute isis instance_10 policy OSPF-redist
    .
    .
    .
  

The area-in attach point within OSPF allows you to filter inbound OSPF type-3 summary link-state advertisements (LSAs). The attach point provides prefix-based matching and hence increased control for filtering type-3 summary LSAs.

The following example shows how to configure the prefix for OSPF summary LSAs. If the prefix matches any of 111.105.3.0/24, 111.105.7.0/24, 111.105.13.0/24, it is accepted. If the prefix matches any of 111.106.3.0/24, 111.106.7.0/24, 111.106.13.0/24, it is dropped.

  route-policy OSPF-area-in
    if destination in (
111.105.3.0/24, 
111.105.7.0/24, 
111.105.13.0/24) then
      drop
    endif
    if destination in (
111.106.3.0/24, 
111.106.7.0/24, 
111.106.13.0/24) then
      pass
    endif
  end-policy
  
  router ospf 1
    area 1
      route-policy OSPF-area-in in 
  

The area-out attach point within OSPF allows you to filter outbound OSPF type-3 summary LSAs. The attach point provides prefix-based matching and, hence, increased control for filtering type-3 summary LSAs.

The following example shows how to configure the prefix for OSPF summary LSAs. If the prefix matches any of 211.105.3.0/24, 211.105.7.0/24, 211.105.13.0/24, it is announced. If the prefix matches any of .105.3.0/24, 212.105.7.0/24, 212.105.13.0/24, it is dropped and not announced.

  route-policy OSPF-area-out
    if destination in (
211.105.3.0/24, 
211.105.7.0/24, 
211.105.13.0/24) then
      drop
    endif
    if destination in (
212.105.3.0/24, 
212.105.7.0/24, 
212.105.13.0/24) then
      pass
    endif
  end-policy
  
  router ospf 1
    area 1
      route-policy OSPF-area-out out
  
  

The spf-prefix-priority attach point within OSPF allows you to define the route policy to apply to OSPFv2 prefix prioritization.

This table summarizes the OSPF attributes and operators per attach points.

The default-information originate attach point allows the user to conditionally inject the default route 0::/0 into the OSPFv3 link-state database, which is done by evaluating the attached policy. If any routes in the local RIB pass the policy, then the default route is inserted into the link-state database.

The following example shows how to generate a default route if any of the routes that match 2001::/96 are present in the RIB:

  route-policy ospfv3-originate
    if rib-has-route in (2001::/96) then
      pass
    endif
  end-policy
  
  router ospfv3 1
    default-information originate policy ospfv3-originate
    .
    .
  

The redistribute attach point within OSPFv3 injects routes from other routing protocol sources into the OSPFv3 link-state database, which is done by selecting the route types it wants to import from each protocol. It then sets the OSPFv3 parameters of cost and metric type. The policy can control how the routes are injected into OSPFv3 by using the metric type command.

The following example shows how to redistribute routes from BGP instance 15 into OSPF instance 1 using the policy OSPFv3-redist. The policy sets the metric type to type-2 for all redistributed routes. BGP routes with a tag of 10 have their cost set to 100, and BGP routes with a tag of 20 have their OSPFv3 cost set to 200. Any BGP routes not carrying a tag of either 10 or 20 are not be redistributed into the OSPFv3 link-state database.

  route-policy OSPFv3-redist
    set metric-type type-2
    if tag eq 10 then
      set extcommunity cost 100
    elseif tag eq 20 then
      set extcommunity cost 200
    else
      drop
    endif
  end-policy
  
  router ospfv3 1
    redistribute bgp 15 policy OSPFv3-redist
    .
    .
    .
  

This table summarizes the OSPFv3 attributes and operators per attach points.

The redistribute attach point within IS-IS allows routes from other protocols to be readvertised by IS-IS. The policy is a set of control structures for selecting the types of routes that a user wants to redistribute into IS-IS. The policy can also control which IS-IS level the routes are injected into and at what metric values.

The following describes an example. Here, routes from IS-IS instance 1 are redistributed into IS-IS instance instance_10 using the policy ISIS-redist. This policy sets the level to level-1-2 for all redistributed routes. IS-IS routes with a tag of 10 have their metric set to 100, and IS-IS routes with a tag of 20 have their IS-IS metric set to 200. Any IS-IS routes not carrying a tag of either 10 or 20 are not be redistributed into the IS-IS database.

  route-policy ISIS-redist
    set level level-1-2
    if tag eq 10 then
      set isis-metric 100
    elseif tag eq 20 then
      set isis-metric 200
    else
      drop
    endif
  end-policy
  
  router isis instance_10
    address-family ipv4 unicast
      redistribute isis 1 policy ISIS-redist
      .
      .
      .
  

The default-information originate attach point within IS-IS allows the default route 0.0.0.0/0 to be conditionally injected into the IS-IS route database.

The following example shows how to generate an IPv4 unicast default route if any of the routes that match 10.0.0.0/8 ge 8 le 25 is present in the RIB. The cost of the IS-IS route is set to 100 and the level is set to level-1-2 on the default route that is injected into the IS-IS database.

  route-policy isis-originate
    if rib-has-route in (10.0.0.0/8 ge 8 le 25) then
      set metric 100
      set level level-1-2
    endif
  end-policy
  
  router isis instance_10
    address-family ipv4 unicast
      default-information originate policy isis_originate
      .
  

The inter-area-propagate attach point within IS-IS allows the prefixes to be conditionally propagated from one level to another level within the same IS-IS instance.

The following example shows how to allow prefixes to be leaked from the level 1 LSP into the level 2 LSP if any of the prefixes match 10.0.0.0/8 ge 8 le 25.

  route-policy isis-propagate
    if destination in (10.0.0.0/8 ge 8 le 25) then
      pass
    endif
  end-policy
  
  
  router isis instance_10
    address-family ipv4 unicast
      propagate level 1 into level 2 policy isis-propagate
      .
  

This table summarizes the IS-IS attributes and operators per attach points.

The default-accept-in attach point allows you to set and reset the conditional default flag for EIGRP routes by evaluating the attached policy.

The following example shows a policy that sets the conditional default flag for all routes that match 10.0.0.0/8 and longer prefixes up to 10.0.0.0/25:

  route-policy eigrp-cd-policy-in
    if destination in (10.0.0.0/8 ge 8 le 25) then
      pass
    endif
  end-policy
  !
  router eigrp 100
    address-family ipv4
      default-information allowed in route-policy eigrp-cd-policy-in
      .
      .
      .
  

The default-accept-out attach point allows you to set and reset the conditional default flag for EIGRP routes by evaluating the attached policy.

The following example shows a policy that sets the conditional default flag for all routes that match 100.10.0.0/16:

  route-policy eigrp-cd-policy-out
    if destination in (
200.10.0.0/16) then
      pass
    endif
  end-policy
  !
  router eigrp 100
    address-family ipv4
      default-information allowed out route-policy eigrp-cd-policy-out
      .
      .
      .
  

The policy-in attach point allows you to filter and modify inbound EIGRP routes. This policy is applied to all interfaces for which there is no interface inbound route policy.

The following example shows the command under EIGRP:

  router eigrp 100
    address-family ipv4
      route-policy global-policy-in in
      .
      .
      .
  

The policy-out attach point allows you to filter and modify outbound EIGRP routes. This policy is applied to all interfaces for which there is no interface outbound route policy.

The following example shows the command under EIGRP:

  router eigrp 100
    address-family ipv4
      route-policy global-policy-out out
      .
      .
      .
  

The if-policy-in attach point allows you to filter routes received on a particular EIGRP interface. The following example shows an inbound policy for GigabitEthernet interface 0/2/0/3:

  router eigrp 100
    address-family ipv4
      interface GigabitEthernet0/2/0/3
        route-policy if-filter-policy-in in
      .
      .
      .
  

The if-policy-out attach point allows you to filter routes sent out on a particular EIGRP interface. The following example shows an outbound policy for GigabitEthernet interface 0/2/0/3:

  router eigrp 100
    address-family ipv4
      interface GigabitEthernet0/2/0/3
        route-policy if-filter-policy-out out
      .
      .
      .
  

The redistribute attach point in EIGRP allows you to filter redistributed routes from other routing protocols and modify some routing parameters before installing the route in the EIGRP database. The following example shows a policy filter redistribution of RIP routes into EIGRP.

  router-policy redistribute-rip
    if destination in (100.1.1.0/24) then
      set eigrp-metric 5000000 4000 150 30 2000
    else
      set tag 200
    endif
  end-policy
  
  router eigrp 100
    address-family ipv4
      redistribute rip route-policy redistribute-rip
      .
      .
      .
  

This table summarizes the EIGRP attributes and operators per attach points.

The default-information originate attach point allows you to conditionally inject the default route 0.0.0.0/0 into RIP updates by evaluating the attached policy. If any routes in the local RIB pass the policy, then the default route is inserted.

The following example shows how to generate a default route if any of the routes that match 10.0.0.0/8 ge 8 le 25 are present in the RIB:

  route-policy rip-originate
    if rib-has-route in (10.0.0.0/8 ge 8 le 25) then
      pass
    endif
  end-policy
  
  router rip
    default-information originate route-policy rip-originate
  

The redistribution attach point within RIP allows you to inject routes from other routing protocol sources into the RIP database.

The following example shows how to inject OSPF routes into RIP:

  route-policy redist-ospf
    set rip-metric 5
  end-policy
  
  router rip
    redistribute ospf 1 route-policy redist-ospf
  

The global-inbound attach point for RIP allows you to filter or update inbound RIP routes that match a route policy.

The following example shows how to filter the inbound RIP routes that match the route policy named rip-in:

  router rip
    route-policy rip-in in
  

The global-outbound attach point for RIP allows you to filter or update outbound RIP routes that match a route-policy.

The following example shows how to filter the outbound RIP routes that match the route policy named rip-out:

  router rip
    route-policy rip-out out
  

The interface-inbound attach point allows you to filter or update inbound RIP routes that match a route policy for a specific interface.

The following example shows how to filter inbound RIP routes that match the route policy for interface 0/1/0/1:

  router rip
    interface GigabitEthernet0/1/0/1
      route-policy rip-in in
  

The interface-outbound attach point allows you to filter or update outbound RIP routes that match a route policy for a specific interface.

The following example shows how to filter outbound RIP routes that match the route policy for interface 0/2/0/1:

  router rip
    interface GigabitEthernet0/2/0/1
      route-policy rip-out out
  

To edit the contents of a routing policy using the Nano editor, use the following CLI command in XR EXEC mode:

  
         edit route-policy 
         
            name
           
         
            nano
           
  
  
      

A copy of the route policy is copied to a temporary file and the editor is launched. After editing, enter Ctrl-X to save the file and exit the editor. The available editor commands are displayed on screen.

Detailed information on using the Nano editor is available at this URL: http://www.nano-editor.org/.

Not all Nano editor features are supported on Cisco IOS XR software.

To edit the contents of a routing policy using the Emacs editor, use the following CLI command in XR EXEC mode:

  
         edit 
         
            route-policy
           
         
            name 
  
            emacs
  
           
  
  
      

A copy of the route policy is copied to a temporary file and the editor is launched. After editing, save the editor buffer by using the Ctrl-X and Ctrl-S keystrokes. To save and exit the editor, use the Ctrl-X and Ctrl-C keystrokes. When you quit the editor, the buffer is committed. If there are no parse errors, the configuration is committed:

  RP/0/RP0/CPU0:router# edit route-policy policy_A
  ----------------------------------------
  == MicroEMACS 3.8b () == rpl_edit.139281 ==
    if destination in (2001::/8) then
      drop
    endif
  end-policy
  !
  
  == MicroEMACS 3.8b () == rpl_edit.139281 ==
  Parsing.
  83 bytes parsed in 1 sec (82)bytes/sec
  Committing.
  1 items committed in 1 sec (0)items/sec
  Updating.
  Updated Commit database in 1 sec 
  
  

If there are parse errors, you are asked whether editing should continue:

  RP/0/RP0/CPU0:router#edit route-policy policy_B
  == MicroEMACS 3.8b () == rpl_edit.141738
  route-policy policy_B
   set metric-type type_1
   if destination in (2001::/8) then
      drop
    endif  
  end-policy
  !
  == MicroEMACS 3.8b () == rpl_edit.141738 ==
  Parsing.
  105 bytes parsed in 1 sec (103)bytes/sec
  
  % Syntax/Authorization errors in one or more commands.!! CONFIGURATION 
  FAILED DUE TO SYNTAX/AUTHORIZATION ERRORS
   set metric-type type_1
   if destination in (2001::/8) then
      drop
    endif
  end-policy
  !
  
  Continue editing? [no]:
  
  

If you answer yes, the editor continues on the text buffer from where you left off. If you answer no, the running configuration is not changed and the editing session is ended.

Editing elements of a routing policy with Vim (Vi IMproved) is similar to editing them with Emacs except for some feature differences such as the keystrokes to save and quit. To write to a current file and exit, use the :wq or :x or ZZ keystrokes. To quit and confirm, use the :q keystrokes. To quit and discard changes, use the :q! keystrokes.

You can reference detailed online documentation for Vim at this URL: http://www.vim.org/

The CLI allows you to enter and delete route policy statements. You can complete a policy configuration block by entering applicable commands such as end-policy or end-set. Alternatively, the CLI interpreter allows you to use the exit command to complete a policy configuration block. The abort command is used to discard the current policy configuration and return to XR Config mode.

RPL supports editing set elements using XML. Entries can be appended, prepended, or deleted to an existing set without replacing it through XML.