This chapter is from the book
This chapter is from the book
This chapter is from the book
Routing Policy Framework
All routing protocols store their routing information in routing tables. From these tables, the routing protocols calculate the best route to each destination and place these routes in a forwarding table. These routes are then used to forward routing protocol traffic toward a destination, and they can be advertised to neighbors using one or more routing protocols. In general, the routing protocols place all their routes in the routing table and advertise a limited set of routes from the routing table. The general rules for handling the routing information between the routing protocols and the routing table are known as the routing policy framework.
Instead of referring to the multiple routing tables that the JUNOS software maintains, this discussion assumes the inet.0 routing table unless explicitly stated otherwise. By default, the JUNOS software stores unicast Internet Protocol Version 4 (IPv4) routes in the inet.0 routing table.
A routing policy is a mechanism in the JUNOS software that allows you to modify the routing policy framework to suit your needs.
The routing policy framework is composed of default rules for each routing protocol that determine which routes the protocol places in the routing table and advertises from the routing table. The default rules for each routing protocol are known as default routing policies. You can create routing policies to preempt the default policies, which are always present. A routing policy is a mechanism in the JUNOS software that allows you to modify the routing policy framework to suit your needs. You can create and implement your own routing policies to control which routes a routing protocol places in the routing table, control which active routes a routing protocol advertises from the routing table, or manipulate the route characteristics as a routing protocol places it in the routing table or advertises it from the routing table.
You might want to preempt the default routing policies in the routing policy framework by creating your own routing policies in the following circumstances:
To not have a protocol to import all routes into the routing table. If the routing table does not learn about certain routes, they can never be used to forward packets, and they can never be redistributed into other routing protocols.
To not have a routing protocol export all the active routes learned by that protocol.
To have a routing protocol announce active routes learned from another routing protocol, which is sometimes called route redistribution.
To manipulate route characteristics, such as the preference value, AS path, or the community. You can manipulate the route characteristics to control which route is selected as the active route to reach a destination. In general, the active route is also advertised to a router's neighbors.
To change the default BGP route flap-damping parameters.
To perform per-packet load balancing.
To enable class of service (CoS).
You can manipulate the route characteristics to control which route is selected as the active route to reach a destination. The active route is placed in the forwarding table and used to forward traffic toward the route's destination. In general, the active route is also advertised to a router's neighbors. To create a routing policy, you must define the policy and apply it. You define the policy by specifying the criteria that a route must match and the actions to perform if a match occurs. You then apply the policy to a routing protocol or to the forwarding table.
To better understand the routing policy framework, it is necessary to define two terms that explain how routes move between the routing protocols and the routing table (see Figure 8.5):
When the Routing Engine places the routes of a routing protocol into the routing table, it is importing routes into the routing table.
When the Routing Engine uses active routes from the routing table to send a protocol advertisement, it is exporting routes from the routing table.
The process of moving routes between a routing protocol and the routing table always is described from the point of view of the routing table. That is, routes are imported into a routing table from a routing protocol, and they are exported from a routing table to a routing protocol. Remember this distinction when working with routing policies.
)
Figure 8.5 Importing and Exporting Routes
When evaluating routes for export, the Routing Engine uses only active routes from the routing table. In other words, an export policy does not evaluate all routes; it evaluates only those routes that a routing protocol is allowed to advertise to a neighbor.
Table 8.2 lists the routing protocols from which the routing table can import routes and to which routing protocols the routing table can export routes. This table also lists direct and explicitly configured routes, which for the purposes of this table are considered a pseudoprotocol. An explicitly configured route is a route that you have configured. Direct routes are not explicitly configured; they are created as a result of IP addresses being configured on an interface. Explicitly configured routes include aggregate, generated, local, and static routes. An aggregate route is a route that distills groups of routes with common addresses into one route. A generated route is a route used when the routing table has no information about how to reach a particular destination. A local route is an IP address assigned to a router interface. A static route is a nonchanging route to a destination.
The policy framework software treats direct and explicitly configured routes as if they are learned through routing protocols; therefore, they can be imported into the routing table. Routes cannot be exported from the routing table to the pseudoprotocol because this protocol is not a real routing protocol. However, aggregate, direct, generated, and static routes can be exported from the routing table to routing protocols, whereas local routes cannot.
For information about the default routing policies for each routing protocol, see Table 8.4. For information about the import and export routing policies supported for each routing protocol and the level at which you can apply these policies, see Table 8.6 on page 320.
Table 8.2 Protocols the Routing Table Can Import from and Export to
|
Protocol |
Import |
Export |
|
Border Gateway Protocol (BGP) |
Yes |
Yes |
|
Distance Vector Multicast Routing Protocol (DVMRP) |
Yes |
Yes |
|
Intermediate System to Intermediate System (IS-IS) |
Yes |
Yes |
|
Label Distribution Protocol (LDP) |
Yes |
Yes |
|
Multiprotocol Label Switching (MPLS) |
Yes |
No |
|
Open Shortest Path First (OSPF) |
Yes |
Yes |
|
Protocol-Independent Multicast (PIM) dense mode |
Yes |
Yes |
|
PIM sparse mode |
Yes |
Yes |
|
Pseudo protocols:
|
Yes |
No |
|
Routing Information Protocol (RIP) and Routing Information Protocol Next-Generation (RIPng) |
Yes |
Yes |
Table 8.3 lists the routing tables affected by default and user-defined routing policies and the types of routes that each routing table stores.
Table 8.3 Routing Tables Affected by Routing Policies
|
Routing Table |
Type of Routes Stored |
|
inet.0 |
Unicast IPv4 routes |
|
instance-name.inet.0 |
Unicast IPv4 routes for a particular routing instance |
|
inet.1 |
Multicast IPv4 routes |
|
inet.2 |
Unicast IPv4 routes for multicast reverse-path forwarding (RPF) lookup |
|
inet.3 |
MPLS routes |
|
mpls.0 |
MPLS routes for label-switched path (LSP) next hops |
|
inet6.0 |
Unicast IPv6 routes |
Table 8.4 summarizes the default routing policies for each routing protocol that imports and exports routes. The actions in the default routing policies are taken if you have not explicitly configured a routing policy.
Table 8.4 Default Routing Policies
|
Importing or Exporting Protocol |
Default Import Policy |
Default Export Policy |
|
BGP |
Import all BGP IPv4 routes learned from configured neighbors into the inet.0 routing table. Import all BGP IPv6 routes learned from configured neighbors into the inet6.0 routing table. |
Export active BGP routes. |
|
DVMRP |
Import all DVMRP routes into the inet.1 routing table. |
Export active DVMRP routes. |
|
IS-IS |
Import all IS-IS routes into the inet.0 and inet6.0 routing tables. (You cannot override or change this default policy.) |
Export active IS-IS routes. Export direct (interface) routes for the interfaces on which IS-IS is explicitly configured. |
|
LDP |
Import all LDP routes into the inet.3 routing table. |
Export active LDP routes. |
|
MPLS |
Import all MPLS routes into the inet.3 routing table. |
Export active MPLS routes. |
|
OSPF |
Import all OSPF routes into the inet.0 routing table. (You cannot override or change this default policy.) |
Export active OSPF routes. Export direct (interface) routes for the interfaces on which OSPF is explicitly configured. |
|
PIM dense mode |
Import all PIM dense mode routes into the inet.1 routing table. |
Export active PIM dense mode routes. |
|
PIM sparse mode |
Import all PIM sparse mode routes into the inet.1 routing table. |
Export active PIM sparse mode routes. |
|
Pseudoprotocol:
|
Import all direct and explicitly configured routes into the inet.0 routing table. |
Does not export any routes. The pseudoprotocol cannot export any routes from the routing table because it is not a routing protocol. Routing protocols can export these or any routes from the routing table. |
|
RIP |
Import all RIP routes learned from configured neighbors into the inet.0 routing table. |
Does not export any routes. To export RIP routes, you must configure an export policy for RIP. |
|
RIPng |
Import all RIPng routes learned from configured neighbors into the inet6.0 routing table. |
Does not export any routes. To export RIPng routes, you must configure an export policy for RIPng. |
When multiple routes for a destination exist in the routing table, the protocol selects an active route, and that route is placed in the appropriate routing table. For equal-cost routes, the JUNOS software places multiple next hops in the appropriate routing table. When a protocol is exporting routes from the routing table, it exports active routes only (applies to actions specified by both default and user-defined export policies).
You cannot change the default import policy for the link-state protocols IS-IS and OSPF. As link-state protocols, IS-IS and OSPF exchange routes between systems within an autonomous system (AS). All routers and systems within an AS must share the same link-state database, which includes routes to reachable prefixes and the metrics associated with the prefixes. If an import policy were configured and applied to IS-IS or OSPF, some routes might not be learned or advertised, or the metrics for learned routes might be altered, which would make a consistent link-state database impossible.
The following default actions are taken if one of the following situations arises during policy evaluation:
If a policy does not specify a match condition, all routes evaluated against the policy match.
If a match occurs but the policy does not specify an accept, reject, next term, or next policy action, one of the following occurs:
The next term, if present, is evaluated.
If no other terms are present, the next policy is evaluated.
If no other policies are present, the action specified by the default policy is taken.
If a match does not occur with a term in a policy and subsequent terms in the same policy exist, the next term is evaluated.
If a match does not occur with any terms in a policy and subsequent policies exist, the next policy is evaluated.
If a match does not occur by the end of a policy or all policies, the accept or reject action specified by the default policy is taken.
When you configure routing policy, you use import routing policies to control which routes routing protocols place in the routing table and export routing policies to control which routes a routing protocol advertises from the routing table to its neighbors (see Figure 8.6).
)
Figure 8.6 Import and Export Routing Policies
To define a routing policy, you create a term that specifies match conditions, which are criteria that a route must match, and actions, which is what to do if a route matches the conditions. The actions can specify whether to accept or reject the route, control how a series of policies is evaluated, and manipulate the characteristics associated with a route. You define match conditions and actions within a term. After defining a routing policy, you then apply it to a routing protocol or to the forwarding table.
Routing policy match conditions fall into two categories: standard and extended (see Table 8.5). In general, the standard match conditions include criteria that are defined within a routing policy and are less complex than the extended match conditions, and the extended match conditions include criteria that are defined separately from the routing policy (AS path regular expressions, communities, and prefix lists) and are more complex than standard match conditions. Some match conditions, including communities, prefix lists, and AS path regular expressions, are defined separately from the routing policy and are given names. You then reference the name of the match condition in the definition of the routing policy itself. Named match conditions allow you to reuse match conditions in other routing policies and read configurations that include complex match conditions with more ease.
Table 8.5 Match Conditions
|
Match Condition |
Category |
When to Use |
Notes |
|
AS path regular expression—Combination of AS numbers and regular expression operators |
Extended |
(BGP only) Match a route based on its AS path. |
— |
|
Community—Group of destinations that share a common property (community information is included as a path attribute in BGP update messages) |
Extended |
Match a group of destinations that share a common property. Use a routing policy to define a community that specifies a group of destinations you want to match and one or more actions that you want taken on this community. |
Actions can be performed on the entire group. You can create multiple communities associated with one particular destination. You can create match conditions using regular expressions. |
|
Prefix list—Named list of IP addresses |
Extended |
Match a route based on prefix information. You can specify an exact match of a particular route only. |
You can specify a common action only for all prefixes in the list. |
|
Route list—List of destination prefixes |
Extended |
Match a route based on prefix information. You can specify an exact match of a particular route or a less precise match. |
You can specify an action for each prefix in the route list or a common action for all prefixes in the route list. |
|
Standard—Collection of criteria that can match a route |
Standard |
Match a route based on one of the following criteria: area ID, color, external route, family, instance (routing), interface name, level number, local preference, metric, neighbor address, next-hop address, origin, preference, protocol, routing table name, or tag. For the protocol criterion, you can specify one of the following: BGP, direct, DVMRP, IS-IS, local, MPLS, OSPF, PIM dense mode, PIM sparse mode, RIP, RIPng, static, and aggregate. |
— |
|
Subroutine—Routing policy that is called repeatedly from another routing policy. |
Extended |
Use an effective routing policy in other routing policies. |
The subroutine action influences but does not necessarily determine the final action. |
An action is what the policy framework software performs if a route matches all criteria defined in a match condition. You can configure one or more actions in a term. The policy framework software supports flow control actions, which affect whether to accept or reject the route or whether to evaluate the next term or routing policy, actions that manipulate route characteristics, and trace action, which logs route matches.
A term is a named structure in which match conditions and actions are defined. You can define one or more terms. In general, the policy framework software compares a route against the match conditions in the first term in the first routing policy, then goes on to the next term and the next policy if present, and so on until an explicitly configured or default action of accept or reject is taken. Therefore, the order in which you arrange terms in a policy is relevant. The order of match conditions in a term is not relevant because a route must match all match conditions in a term for an action to be taken.
After defining a routing policy, you can apply it to routing protocols, to a pseudoprotocol (explicitly created routes, which include aggregate and generated routes), and to the forwarding table. Table 8.6 summarizes the import and export policy support for each routing protocol. You can apply an import policy to aggregate and generated routes, but you cannot apply an export policy to these routes. These routes cannot be exported from the routing table to the pseudoprotocol, because this protocol is not a real routing protocol. However, aggregate and generated routes can be exported from the routing table to routing protocols.
Table 8.6 Apply Routing Policies to Protocols
|
Protocol |
Import Policy |
Export Policy |
Supported Levels |
|
BGP |
Yes |
Yes |
Import: global, group, peer Export: global, group, peer |
|
DVMRP |
Yes |
Yes |
Global |
|
IS-IS |
No |
Yes |
Export: global |
|
LDP |
Yes |
Yes |
Global |
|
MPLS |
No |
No |
— |
|
OSPF |
No |
Yes |
Export: global |
|
PIM dense mode |
Yes |
Yes |
Global |
|
PIM sparse mode |
Yes |
Yes |
Global |
|
Pseudoprotocol—Explicitly configured routes, including aggregate routes and generated routes |
Yes |
No |
Import: global |
|
RIP and RIPng |
Yes |
Yes |
Import: global, neighbor Export: group |
For BGP only, you can also apply import and export policies at group and peer levels as well as at the global level. A peer import or export policy overrides a group import or export policy. A group import or export policy overrides a global import or export policy.
For RIP and RIPng only, you can apply import policies at the global and neighbor levels and export policies at a group level.
You can apply export policies to routes being exported from the routing table into the forwarding table for per-packet load balancing and CoS.
Figure 8.7 shows how a single routing policy is evaluated. This routing policy consists of multiple terms. Each term consists of match conditions and actions to apply to matching routes. Each route is evaluated against the policy as follows:
)
Figure 8.7 Routing Policy Evaluation
The route is evaluated against the first term. If it matches, the specified action is taken. If the action is to accept or reject the route, that action is taken and the evaluation of the route ends. If the next term action is specified, if an action is not specified, or if the route does not match, the evaluation continues as described in Step 2. If the next policy action is specified, any accept or reject action specified in this term is skipped, all remaining terms in this policy are skipped, all other actions are taken, and the evaluation continues as described in Step 3.
The route is evaluated against the second term. If it matches, the specified action is taken. If the action is to accept or reject the route, that action is taken and the evaluation of the route ends. If the next term action is specified, if an action is not specified, or if the route does not match, the evaluation continues in a similar manner against the last term. If the next policy action is specified, any accept or reject action specified in this term is skipped, all remaining terms in this policy are skipped, all other actions are taken, and the evaluation continues as described in Step 3.
If the route matches no terms in the routing policy or the next policy action is specified, the accept or reject action specified by the default policy is taken.
Figure 8.8 shows how a chain of routing policies is evaluated. These routing policies consist of multiple terms. Each term consists of match conditions and actions to apply to matching routes. Each route is evaluated against the policies as follows:
The route is evaluated against the first term in the first routing policy. If it matches, the specified action is taken. If the action is to accept or reject the route, that action is taken and the evaluation of the route ends. If the next term action is specified, if an action is not specified, or if the route does not match, the evaluation continues as described in Step 2. If the next policy action is specified, any accept or reject action specified in this term is skipped, all remaining terms in this policy are skipped, all other actions are taken, and the evaluation continues as described in Step 3.
The route is evaluated against the second term in the first routing policy. If it matches, the specified action is taken. If the action is to accept or reject the route, that action is taken and the evaluation of the route ends. If the next term action is specified, if an action is not specified, or if the route does not match, the evaluation continues in a similar manner against the last term in the first routing policy. If the next policy action is specified, any accept or reject action specified in this term is skipped, all remaining terms in this policy are skipped, all other actions are taken, and the evaluation continues as described in Step 3.
If the route does not match a term or matches a term with a next policy action in the first routing policy, it is evaluated against the first term in the second routing policy.
The evaluation continues until the route matches a term with an accept or reject action defined or until there are no more routing policies to evaluate. If there are no more routing policies, the accept or reject action specified by the default policy is taken.
)
Figure 8.8 Routing Policy Chain Evaluation
Figure 8.9 on page 325 shows how a subroutine is evaluated. The subroutine is included in the first term of the first routing policy in a chain. Each route is evaluated against the subroutine as follows:
The route is evaluated against the first term in the first routing policy. If the route does not match all match conditions specified before the subroutine, the subroutine is skipped and the next term in the routing policy is evaluated (see Step 2). If the route matches all match conditions specified before the subroutine, the route is evaluated against the subroutine. If the route matches the match conditions in any of the subroutine terms, two levels of evaluation occur in the following order:
The actions in the subroutine term are evaluated. If one of the actions is accept, evaluation of the subroutine ends and a Boolean value of TRUE is returned to the calling policy. If one of the actions is reject, evaluation of the subroutine ends and FALSE is returned to the calling policy. If one of the actions is meant to manipulate route characteristics, the characteristic is changed regardless of whether accept, reject, or neither action is specified.
If the subroutine does not specify the accept or reject actions, it uses the accept or reject action specified by the default policy and the values of TRUE or FALSE are returned to the calling policy as described above.
The calling policy's subroutine match condition is evaluated. During this part of the evaluation, TRUE equals a match and FALSE equals no match. If the subroutine returned TRUE to the calling policy, then the evaluation of the calling policy continues. If the subroutine returned FALSE to the calling policy, then the evaluation of the current term ends and the next term is evaluated.
The route is evaluated against the second term in the first routing policy. If a term defines multiple match conditions, including a subroutine, and a route does not match a condition specified before the subroutine, the evaluation of the term ends and the subroutine is not called and evaluated. In this situation, an action specified in the subroutine that manipulates a route's char-acteristics is not implemented. If you specify a policy chain as a subroutine, the entire chain acts as a single subroutine. That is, as with other chains, the action specified by the default policy is taken only when the entire chain does not accept or reject a route.
)
Figure 8.9 Routing Policy Subroutine Evaluation