6. Route Policies

6.1. In This Chapter

This chapter provides information about configuring route policies.

6.2. Configuring Route Policies

The 7210 SAS supports two databases for routing information. The routing database is composed of the routing information learned by the routing protocols. The forwarding database is composed of the routes actually used to forward traffic through a router. In addition, link state databases are maintained by interior gateway protocols (IGPs), such as IS-IS and OSPF.

Routing protocols calculate the best route to each destination and place these routes in a forwarding table. The routes in the forwarding table are used to forward routing protocol traffic, sending advertisements to neighbors and peers.

A routing policy can be configured that will not place routes associated with a specific origin in the routing table. Those routes will not be used to forward data packets to the intended destinations and the routes are not advertised by the routing protocol to neighbors and peers.

Routing policies control the size and content of the routing tables, the routes that are advertised, and the best route to take to reach a destination. Careful planning is essential to implement route policies that can affect the flow of routing information or packets in and traversing through the router. Before configuring and applying a route policy, develop an overall plan and strategy to accomplish your intended routing actions.

There are no default route policies. Each policy must be created explicitly and applied to a routing protocol or to the forwarding table. Policy parameters are modifiable.

6.2.1. Policy Statements

Route policies contain policy statements containing ordered entries containing match conditions and actions you specify. The entries should be sequenced from the most explicit to least explicit. Packet forwarding and routing can be implemented according to your defined policies. Policy-based routing allows you to dictate where traffic can be routed, through specific paths, or whether to forward or drop the traffic. Route policies can match a specific route policy entry and continue searching for other matches within either the same route policy or the next route policy.

The process can stop when the first complete match is found and executes the action defined in the entry, either to accept or reject packets that match the criteria or proceed to the next entry or the next policy. You can specify matching criteria based on source, destination, or particular properties of a route. Route policies can be constructed to support multiple stages to the evaluation and setting various route attributes. You can also provide more matching conditions by specifying criteria, such as:

  1. Prefix list — A named list of prefixes.
  2. To and From criteria — A route’s source and destination.

6.2.1.1. Default Action Behavior

The default action specifies how packets are to be processed when a policy related to the route is not explicitly configured. The following default actions are applied in the event that:

  1. A route policy does not specify a matching condition, all the routes being compared with the route policy are considered to be matches.
  2. A packet does not match any policy entries, then the next policy is evaluated. If a match does not occur then the last entry in the last policy is evaluated.
  3. If no default action is specified, the default behavior of the protocol controls whether the routes match or not.

If a default action is defined for one or more of the configured route policies, then the default action is handled as follows:

  1. The default action can be set to all available action states including accept, reject, next-entry, and next-policy.
  2. If the action states accept or reject, then the policy evaluation terminates and the appropriate result is returned.
  3. If a default action is defined and no matches occurred with the entries in the policy, then the default action is used.
  4. If a default action is defined and one or more matches occurred with the entries of the policy, then the default action is not used.

6.2.1.2. Denied IP Prefixes

The following IP address prefixes are not allowed by the routing protocols and the Route Table Manager and are not be populated within the forwarding table:

  1. 0.0.0.0/8 or longer
  2. 127.0.0.0/8 or longer
  3. 224.0.0.0/4 or longer
  4. 240.0.0.0/4 or longer

Any other prefixes that need to be filtered can be filtered explicitly using route policies.

6.2.1.3. Controlling Route Flapping

Route damping is a controlled acceptance of unstable routes from BGP peers so that any ripple effect caused by route flapping across BGP AS border routers is minimized. The motive is to delay the use of unstable routes (flapping routes) to forward data and advertisements until the route stabilizes.

Nokia implementation of route damping is based on the following parameters:

  1. Figure of Merit
    A route is assigned a Figure of Merit (FoM), proportional to the frequency of flaps. FoM should be able to characterize a route’s behavior over a period of time.
  2. Route flap
    A route flap is not limited to the withdrawn route. It also applies to any change in the AS path or the next hop of a reachable route. A change in AS path or next hop indicates that the intermediate AS or the route-advertising peer is not suppressing flapping routes at the source or during the propagation. Even if the route is accepted as a stable route, the data packets destined to the route could experience unstable routing due to the unstable AS path or next hop.
  3. Suppress threshold
    The threshold is a configured value that, when exceeded, the route is suppressed and not advertised to other peers. The state is considered to be down from the perspective of the routing protocol.
  4. Reuse threshold
    When FoM value falls below a configured reuse threshold and the route is still reachable, the route is advertised to other peers. The FoM value decays exponentially after a route is suppressed. This requires the BGP implementation to decay thousands of routes from a misbehaving peer.

Events that could trigger the route flapping algorithm are:

  1. Route flapping
    If a route flap is detected within a configured maximum route flap history time, the route’s FoM is initialized and the route is marked as a potentially unstable route. Every time a route flaps, the FoM is increased and the route is suppressed if the FoM crosses the suppress threshold.
  2. Route reuse timer trigger
    A suppressed route’s FoM decays exponentially. When it crosses the reuse threshold, the route is eligible for advertisement if it is still reachable.

If the route continues to flap, the FoM, with respect to time scale, looks like a sawtooth waveform with the exponential rise and decay of FoM. To control flapping, the following parameters can be configured:

  1. half-life
    The half life value is the time, expressed in minutes, required for a route to remain stable in order for one half of the FoM value to be reduced. For example, if the half life value is 6 (minutes) and the route remains stable for 6 minutes, then the new FoM value is 3. After another 6 minutes passes and the route remains stable, the new FoM value is 1.5.
  2. max-suppress
    The maximum suppression time, expressed in minutes, is the maximum amount of time that a route can remain suppressed.
  3. suppress
    If the FoM value exceeds the configured integer value, the route is suppressed for use or inclusion in advertisements.
  4. reuse
    If the suppress value falls below the configured reuse value, then the route can be reused.

6.3. Regular Expressions

The ability to perform a filter match on confederations in the AS-PATH is supported. This feature allows customers to configure match criteria for specific confederation sets and sequences within the AS path so that they can be filtered out before cluttering the service provider’s routing information base (RIB).

7210 SAS uses regular expression strings to specify match criteria for:

  1. An AS path string; for example, “100 200 300”
  2. A community string; for example, “100:200” where 100 is the ASN, and 200 is the community-value.
  3. Any AS path beginning with a confederation SET or SEQ containing 65001 and 65002 only: for example “< 65001 65002 >.*”
  4. Any AS path containing a confederation SET or SEQ, regardless of the contents: for example, “.* <.*> .*”

A regular expression is expressed in terms of terms and operators. A term for an AS path regular expression is:

  1. Regular expressions should always be enclosed in quotes.
  2. An elementary term; for example, an ASN “200”
  3. A range term composed of two elementary terms separated by the ‘-’ character like “200-300”.
  4. The '.' dot wild-card character which matches any elementary term.
  5. A regular expression enclosed in parenthesis “( )”.
  6. A regular expression enclosed in square brackets used to specify a set of choices of elementary or range terms; for example. [100-300 400] matches any ASN between 100 and 300 or the ASN 400.

A term for a community string regular expression is a string that is evaluated character by character and is composed of:

  1. An elementary term which for a community string is any single digit like “4”.
  2. A range term composed of two elementary terms separated by the ‘-’ character like “2-3”.
  3. A colon ':' to delimit the ASN from the community value
  4. The '.' dot wild-card character which matches any elementary term or ':'.
  5. A regular expression enclosed in parenthesis “( )”.
  6. A regular expression enclosed in square brackets used to specify a set of choices of elementary or range terms; for example, [1-37] matches any single digit between 1 and 3 or the digit 7.

The regular expression OPERATORS are listed in Table 76.

Table 76:  Regular Expression Operators  

Operator

Description

|

Matches the term on alternate sides of the pipe.

*

Matches multiple occurrences of the term.

?

Matches 0 or 1 occurrence of the term.

+

Matches 1 or more occurrence of the term.

( )

Used to parenthesize so a regular expression is considered as one term.

[ ]

Used to demarcate a set of elementary or range terms.

-

Used between the start and end of a range.

{m,n}

Matches least m and at most n repetitions of the term.

{m}

Matches exactly m repetitions of the term.

{m,}

Matches m or more repetitions of the term.

^

Matches the beginning of the string - only allowed for communities.

$

Matches the end of the string - only allowed for communities.

\

An escape character to indicate that the following character is a match criteria and not a grouping delimiter.

Examples of AS path and community string regular expressions are listed in Table 77.

Table 77:  AS Path and Community Regular Expression Examples  

AS Path to Match Criteria

Regular Expression

Example Matches

Null AS path

null  a

Null AS path

AS path is 11

11

11

AS path is 11 22 33

11 22 33

11 22 33

Zero or more occurrences of ASN 11

11*

Null AS path

11

11 11

11 11 11

11 … 11

Path of any length that begins with AS numbers 11, 22, 33

11 22 33 .*

11 22 33

11 22 33 400 500 600

Path of any length that ends with AS numbers 44, 55, 66

.* 44 55 66

44 55 66

100 44 55 66

100 200 44 55 66

100 200 300 44 55 66

100 200 300 … 44 55 66

One occurrence of the AS numbers 100 and 200, followed by one or more occurrences of the number 33

100 200 33+

100 200 33

100 200 33 33

100 200 33 33 33

100 200 33 33 33 … 33

One or more occurrences of ASN 11, followed by one or more occurrences of ASN 22, followed by one or more occurrences of ASN 33

11+ 22+ 33+

11 22 33

11 11 22 33

11 11 22 22 33

11 11 22 22 33 33

11 … 11 22 … 22 33 …33

Path whose second ASN must be 11 or 22

(. 11) | (. 22) .*

or

. (11 | 22) .*

100 11

200 22 300 400

…

Path of length one or two whose second ASN might be 11 or 22

. (11 | 22)?

100

200 11

300 22

Path whose first ASN is 100 and second ASN is either 11 or 22

100 (11 | 22) .*

100 11

100 22 200 300

Either AS path 11, 22, or 33

[11 22 33]

11

22

33

Range of AS numbers to match a single ASN

10-14

10 or 11 or 12 or 13 or 14

[10-12]*

Null AS path

10 or 11 or 12

10 10 or 10 11 or 10 12

11 10 or 11 11 or 11 12

12 10 or 12 11 or 12 12

…

Zero or one occurrence of ASN 11

11? or 11{0,1}

Null AS path

11

One through four occurrences of ASN 11

11{1,4}

11

11 11

11 11 11

11 11 11 11

One through four occurrences of ASN 11 followed by one occurrence of ASN 22

11{1,4} 22

11 22

11 11 22

11 11 11 22

11 11 11 11 22

Path of any length, except nonexistent, whose second ASN can be anything, including nonexistent

. .* or . .{0,}

100

100 200

11 22 33 44 55

ASN is 100. Community value is 200.

^100:200$

100:200

ASN is 11 or 22. Community value is any number.

^((11)|(22)):(.*)$

11:100

22:100

11:200

…

ASN is 11. Community value is any number that starts with 1.

^11:(1.*)$

11:1

11:100

11:1100

…

ASN is any number. Community value is any number that ends with 1, 2, or 3.

^(.*):(.*[1-3])$

11:1

100:2002

333:55553

…

ASN is 11 or 22. Community value is any number that starts with 3 and ends with 4, 5 or 9.

^((11)|(22)):(3.*[459])$

11:34

22:3335

11:3777779

…

ASN is 11 or 22. Community value ends in 33 or 44.

[^((11|22)):(.*((33)|(44)))$

11:33

22:99944

22:555533

…

    Note:

  1. The null keyword matches an empty AS path.

6.3.1. BGP and OSPF Route Policy Support

OSPF and BGP requires route policy support. Figure 24 and Figure 25 show where route policies are evaluated in the protocol. Figure 24 shows BGP which applies a route policy as an internal part of the BGP route selection process. Figure 25 shows OSPF which applies routing policies at the edge of the protocol, to control only the routes that are announced to or accepted from the Route Table Manager (RTM).

Figure 24:  BGP Route Policy Diagram 

6.3.1.1. BGP Route Policies

The Nokia implementation of BGP uses route policies extensively. The implied or default route policies can be overridden by customized route policies. The default BGP properties, with no route policies configured, behave as follows:

  1. Accept all BGP routes into the RTM for consideration.
  2. Announce all used BGP learned routes to other BGP peers
  3. Announce none of the IGP, static or local routes to BGP peers.
    Figure 25 shows the OSPF route policy.
    Figure 25:  OSPF Route Policy Diagram 

6.3.1.2. Re-advertised Route Policies

Occasionally, BGP routes may be readvertised from BGP into OSPF, IS-IS. OSPF export policies control which routes are exported to OSPF) are not handled by the main OSPF task but are handled by a separate task or an RTM task that filters the routes before they are presented to the main OSPF task.

6.3.2. When to Use Route Policies

The following are examples of circumstances of when to configure and apply unique route policies.

  1. When you want to control the protocol to allow all routes to be imported into the routing table. This enables the routing table to learn about particular routes to enable packet forwarding and redistributing packets into other routing protocols.
  2. When you want to control the exporting of a protocol’s learned active routes.
  3. When you want a routing protocol to announce active routes learned from another routing protocol, which is sometimes called route redistribution.
  4. Route policies can be used to filter IGMP membership reports from specific hosts and/or specific multicast groups.
  5. When you want unique behaviors to control route characteristics. For example, change the route preference.
  6. When you want unique behaviors to control route characteristics. For example, change the route preference, AS path, or community values to manipulate the control the route selection.
  7. When you want to control BGP route flapping (damping).

6.4. Route Policy Configuration Process Overview

Figure 26 shows the process to provision basic route policy parameters.

Figure 26:  Route Policy Configuration and Implementation Flow 

6.5. Configuration Notes

This section describes route policy configuration caveats.

6.5.1. General

When configuring policy statements, the policy statement name must be unique.