11.3 Structure of JUNOS Routing Policy Language

The JUNOS policy language is very similar to a programming language in the way the configuration is laid out and how it can be subdivided into modules. Individuals familiar with programming will see that JUNOS policy configurations are similar in layout to Pascal or C programs. The same parsing rules apply for curly braces ({ ) and semicolons (;) in JUNOS as they do in the aforementioned programming languages.

The most important aspect of using any good programming language is its implementation. The same can be said of the JUNOS policy language. Policies can be broken down into modules with specific actions; this makes the language very scalable and adaptable to the needs of today's large networks.

Policy definition is carried out in configuration mode at the [edit policy-options] level of the JUNOS CLI. Policies are defined by using the policy-statement command as follows :

 [edit]  user@SanFrancisco# edit policy-options [edit policy-options] root@SanFran# set policy-statement policyname ? Possible completions: + apply-groups         Groups from which to inherit configuration data > from                 Conditions to match a route's source > term                 Policy term > then                 Actions to take if 'from' and 'to' conditions match > to                   Conditions to match a route's destination 

After naming a policy, as shown above, you have the option of creating terms or defining a simple policy without terms. The same concepts for configuration development presented in Section 6.3 on firewall filters apply here. Each policy consists of zero or more terms with each term consisting of match conditions specified using a from or to statement and match actions specified using a then statement. If no terms are specified, match conditions and match actions are specified at the policy level only. An analogy to this would be a computer program consisting of subroutines with if then else statements. The computer program represents the policy, and the subroutines are the individual terms within the policy.

• In a from statement, a match condition is specified to correspond to one or more routes received from neighbors, adjacencies, peers, or a specific protocol.

• In a to statement, a match condition is specified to match against one or more routes being advertised from the routing table destined for neighbors, adjacent routers, peers, or a specific routing protocol.

• In a then statement, the actions to be taken once a match is made are specified.

Multiple routing policies can be combined to create a policy chain, which uses an ordered list of policies. In a policy chain, each link is a predefined policy. This is a very efficient way of developing complex policies by reusing predefined policies instead of creating longer and more complex ones. The chain of match conditions is stopped once an accept or reject match action is reached in any of the policies.

Why would we want to use a chain as opposed to a single policy with multiple terms? Policy chains can assist in optimizing smaller, more concise configurations by restricting common elements to specific policies and reusing those policies instead of re-creating them. A good example of this would be a policy to reject inbound default routes and private addresses from an external AS. This type of policy could be applied to BGP neighbors at the beginning of a chain. The remaining policies included in the chain could apply to specific BGP groups or neighbors. More examples of policy chains are discussed in subsequent sections of this chapter and are shown in Figure 11-3.

Figure 11-3. Rating Policy Chain

11.3.1 Default Routing Policy Actions

Each routing protocol has a certain default action that it performs when a routing policy is applied to it. As we have discussed there are both import and export routing policies and if you have not explicitly configured a desired routing policy then the defaults listed in Table 11-2.

When referring to this table keep in mind that Juniper Networks refers to directly connected and explicitly routes (ex. Static) as pseudoprotocol routes since they do not originate from a specific routing protocol.

Table 11-2. Default Routing Policies

Imported/Exported Protocol	Default Import Policy Operation	Default Export Policy Operation
RIP	Import all RIP routes learned from configured neighbors into the inet.0 routing table.	RIP will not export any routes by default. To export RIP routes, you must configure an export policy.
RIPng	Import all RIPng routes learned from configured neighbors into the inet6.0 routing table.	RIP will not export any routes by default. To export RIPng routes, you must configure an export policy.
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 all active IS-IS routes. Export all direct (interface) routes for the interfaces on which IS-IS is explicitly configured.
OSPF	OSPF Import all OSPF routes into the inet.0 routing table. (You cannot override or change this default policy.)	Export all active OSPF routes. Export all direct (interface) routes for the interfaces on which OSPF is explicitly configured.
BGP	Import all BGP IPv4 routes learned from the routers configured neighbors into the inet.0 routing table. Import all BGP IPv6 routes learned from configured neighbors into the inet6.0 routing table.	Export all active BGP routes.
LDP	Import all LDP routes into the inet .3 routing table.	Export all active LDP routes.
MPLS	Import all MPLS routes into the inet.3 routing table.	Export all active MPLS routes.
DVMRP	Import all DVMRP routes into the inet.1 routing table.	Export all active DVMRP routes.
PIM Dense Mode	Import all PIM dense mode routes into the inet.1 routing table.	Export all active PIM dense mode routes.
PIM Sparse Mode	Import all PIM sparse mode routesinto the inet.1 routing table.	Export all active PIM sparse mode routes.
Pseudoprotocol Routes Include: Direct routes Explicitly configured routes: Aggregate routes Generated routes Static routes	Import all direct and explicitly configured routes into the inet.0 routing table.	Does not by default export any routes. The pseudoprotocol cannot export any routes from the routing table because it is not a routing protocol, rather it is a collection of routes that fir into one of the listed categories. Routing protocols can export these or any routes from the routing table.

Note

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 routers within an autonomous system (AS). All routers within an AS (or area) 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 .

11.3.2 Policy-Chain Terms

A term is a segment of a policy designed to match routes against user-specified criteria and perform specific actions on them once a match is made. A policy may have a single term, multiple terms, or none at all. Each policy can have specific match actions within each term, as well as default actions outside of the terms. This concept is illustrated in Figure 11-4.

Figure 11-4. Policy Structure

Routes are sequentially passed into the first policy in the chain ”in this example it is referred to as Policy 1. Policy 1 sends the routes through Term 1 and compares them to the match conditions specified. If a match is made against a route and if the route is accepted or rejected, no further comparisons are made and any other actions specified are carried out. If an accept or reject is not specified in the match actions or if there are no matches in Term 1, then the routes are passed on to Term 2.

Keep in mind that match actions may occur against a route that simply modifies the properties of a route without accepting or rejecting it. Routes that are not explicitly accepted or rejected by a match action continue to be evaluated in the policy chain. This procedure continues for T terms in Policy 1 where T is a numeric integer defining the number of terms in a policy. If Term T has been evaluated without a match, then the routes are passed to the next policy in the chain, which in this case is Policy 2. Routes that do not match any policies in the chain through an accept action will be rejected.

Not all policies or terms will have from , to , and then statements present. There are a number of rules to determine what occurs if all or only some of these statements are present. This process is illustrated in Figure 11-5 and described below.

• The following default actions are taken if one of the following situations arise 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.

Figure 11-5. Policy Flow

11.3.3 Match Conditions

Both from and to statements are made up of match conditions. There are many conditions that a route can be matched against, which are divided into generic and protocol categories. As previously discussed, a protocol-specific match condition, such as the OSPF area number, is considered to be a unique characteristic used by that protocol. A complete list of the possible from statements is contained in the following example from the CLI:

 [edit]  user@Chicago# edit policy-options policy-statement my-new-policy [edit policy-options policy-statement my-new-policy] user@Chicago# set from ? Possible completions: + apply-groups         Groups from which to inherit configuration data   area                 OSPF area identifier + as-path              Name of AS path regular expression (BGP only)   color                Color (preference) value   color2               Color (preference) value 2 + community            BGP community > external             External route   instance             Routing protocol instance + interface            Interface name or address   level                IS-IS level   local-preference     Local preference associated with a route   metric               Metric value   metric2              Metric value 2   metric3              Metric value 3   metric4              Metric value 4 + neighbor             Neighboring router + next-hop             Next-hop router   origin               BGP origin attribute + policy               Name of policy to evaluate   preference           Preference value   preference2          Preference value 2 > prefix-list          List of prefix-lists of routes to match + protocol             Protocol from which route was learned   rib                  Routing table > route-filter         List of routes to match > source-address-filter  List of source addresses to match   tag                  Tag string   tag2                 Tag string 2 

Table 11-3 describes the each of the generic match conditions in more detail.

Table 11-3. Generic Match Conditions

Match Condition	Description
color and color2	Matches fine-grained preference values; often associated with BGP communities.
external	Matches external routes, including those exported from one level to another. A metric or type can be specified. If a type is not specified, then all external routes are matched, but if a type is specified, then the match will look for external type 1 or 2 routes, which are a feature of the OSPF protocol.
instance	Matches routes coming from a specific protocol entity on the router.
interface	Matches all routes learned via a specific interface. Do not use this with protocols that are not interface specific, such as IBGP.
metric, metric2, metric3, metric4	Matches routes against four specifiable metric values. For BGP, metric corresponds to MED , and metric2 corresponds to the IGP metric if the BGP next-hop traverses another route.
neighbor	Matches routes from an OSPF or BGP neighbor or an IS-IS adjacency .
next-hop	Matches routes tagged with a specific next-hop address.
policy	Used to invoke routes that passed another policy. It saves having to rewrite policy statements.
preference and preference2	Two preference values can be specified for a route. The preference2 value is used if there is a tie in the evaluation of the primary preference values. Also, color and color2 can be used as finer-grained preference values.
protocol	Matches against the protocol from which the route was learned.
rib	Routes can be matched against a specific routing table. This defaults to the unicast routing table inet.0 if a routing table is not specified, such as inet.1 , inet.2 , or mpls.0 .

The following example shows a simple policy that rejects OSPF type 2 external routes:

 policy-statement external-type2-reject {          from {             protocol ospf;             external {                 type 2;             }         }         then reject;     } 

The next example shows a policy that could be used to change the metric of routes from a specific routing instance, in this case ospf2 , assuming the router is running multiple instances of OSPF. ospf2 is the second instance of OSPF routing configured on the router:

 policy-statement routes-from-ospf2 {          from {             instance ospf2;             protocol ospf;         }         then {             metric 10;             accept;         }     } 

Another example is a simple routing policy that matches all RIP routes, as follows:

 policy-statement match-rip-routes {      from protocol rip;     then accept; } 

There are also protocol-specific match conditions for OSPF, IS-IS, and BGP. Table 11-4 lists and describes each of the protocol-specific match conditions.

Table 11-4. Protocol-Specific Match Conditions

Match Condition	Protocol	Description
area	OSPF	Matches routes learned from a specific OSPF area when exporting routes
as-path	BGP	Matches routes against an AS path regular expression
community	BGP	Matches routes against one or more BGP communities
level	IS-IS	Matches routes based on the IS-IS router level as received
local-preference	BGP	Matches routes based on their BGP local preference value
origin	BGP	Matches routes based on the source of the AS path information (IGP, EGP, or incomplete)
tag and tag2	OSPF	Matches routes against the contents of OSPF's external LSA 32-bit tag fields

Examples of the various BGP match conditions will be explored in greater depth later in the chapter and in Chapter 10.

11.3.4 Match Actions

After the match conditions in the from and to statements have been selected, it is then time to select a corresponding match action for the policy. All match actions are specified as part of a then statement. As with match conditions, there are many match actions. The possible match actions are listed below:

 [edit policy-options policy-statement policyname]  Lab@Chicago# set then ? Possible completions:   accept               Accept a route + apply-groups         Groups from which to inherit configuration data   as-path-prepend      Prepend AS numbers to an AS path (BGP only)   class                Set class-of-service parameters > color                Color (preference) value > color2               Color (preference) value 2 > community            BGP community properties associated with a route   cos-next-hop-map     Set CoS based next hop map in forwarding table   damping              Define BGP route flap damping parameters   destination-class    Set destination class in forwarding table > external             External route > install-nexthop      Choose the next-hop to be used for forwarding > load-balance         Type of load balancing in forwarding table > local-preference     Local preference associated with a route > metric               Metric value > metric2              Metric value 2 > metric3              Metric value 3 > metric4              Metric value 4   next                 Skip to next policy or term > next-hop             Set the address of the next-hop router   origin               BGP path origin > preference           Preference value > preference2          Preference value 2   reject               Reject a route > tag                  Tag string > tag2                 Tag string 2   trace                Log matches to a trace file 

Match actions can be divided into three distinct groups:

1. Control actions

2. Tracing action

3. General policy actions

Control actions govern the policy flow. These are the most fundamental match actions and the most frequently used. Table 11-5 lists and describes each of the control actions.

Table 11-5. Control Actions

Match Action	Description
accept	The matched route is accepted and no further matching is carried out.
reject	The matched route is rejected and no further matching is carried out.
ext policy	Skips ahead to the next policy. If an accept or reject action is not specified, and a match has occurred, then this is the default action. If there are no further policies, a default policy action is taken.
next term	Skips to the next term. This is also default behavior if an accept or reject action is not specified in the term. If there are no further terms, then the next policy is evaluated, and if there are no further policies, a default policy action is taken.

The trace action logs the match to a trace file. You will already have some information on trace files from Section 6.2.5.1, and more tracing examples will be explored in the next chapter. Trace file configurations appear at the routing-options level as follows:

 routing-options {      traceoptions {         file matchactionlog replace size 640k files 5 no-world-readable;         flag policy;     } } 

The remaining match actions fall under the general policy-actions category and are normally used to modify parameters associated with a route. Table 11-6 lists each of these actions.

Table 11-6. General Policy Actions

Match Action	Description
as-path-prepend	Prepends one's ASN one or more times to the beginning of an AS path to make a route less favorable to BGP.
class	Applies CoS parameters to routes before they are installed in the routing table.
color and color2	Sets the preference of a route to a value between 1 and 2321. A color can be seen as an internal preference value that is local to the router and nontransitive. A color option specified on its own is used to denote a preference where there previously was none. If dealing with a preference value that is already present, it can be modified by adding or subtracting a constant, using the add and subtract options.
community set	Sets the BGP community attribute where there previously was none or overwrites an attribute that is already present.
community add	Adds a BGP community attribute to a route.
community delete	Deletes a BGP community attribute from a route.
damping	Configures route flap damping parameters as part of routing policy. Enables suppression of flapping routes.
destination-class	Relates destination class usage to maintain packet counts for specific routes. Destination class usage policies are applied to the forwarding table.
external	Sets the external metric type of an OSPF route.
install-nexthop lsp	Used in conjunction with an MPLS LSP to specify which next-hops are installed in the routing table.
load-balance- per-packet	Installs all next-hop addresses in the forwarding table for the active route and performs per-packet load balancing.
local-preference	Sets a BGP local preference parameter for a route.
metric	Like from and to statements, comprises four possible metrics for each route: metric , metric2 , metric3 , and metric4 . The add and subtract options exist to modify existing metric options. Otherwise, any existing metrics are overwritten.
anext-hop	Sets the next-hop information for BGP. A common scenario where this is used is in the next-hop self statement, which is used to replace the existing next-hop with the address of the local router.
origin	Can be set to one of three values: igp , egp , or incomplete .
preference or preference2	Associates a preference value with a route. By default, all routes will have their preference set based on protocol origin. Routes with the lowest preference are preferred. The preference2 value serves as a tiebreaker if preference values are equal. Furthermore the color and color2 values can be used for further granularity. As with the color and color2 actions, add and subtract options exist for both preference and preference2 to modify an existing preference . Otherwise any existing preference values are overwritten.
tag and tag2	Sets the tag and tag2 fields in OSPF external LSA packets. The add and subtract options are also used to modify existing values in either of these fields.

In the following example, the AS path attribute of all routes received from BGP peer 10.0.0.1 will be prepended with "2 2 2 2" , making these routes less attractive to BGP for inbound traffic, where 2 is the number of the local AS.

 policy-options {      policy-statement as-path-prepend {         from neighbor 10.0.0.1;         then as-path-prepend "2 2 2 2";         accept;     } } 

The next example enables damping with the options contained in lots-of-damping . The damping parameters for lots-of-damping are specified in a separate section of policy. This will be examined in greater detail in Section 11.6.

 policy-options {      policy-statement my-damp {         from neighbor 10.0.0.1;         then damping lots-of-damping;     } 

The following example matches against routes coming from a specific next-hop 10.0.0.1 and going to OSPF area 3 while setting the preference value to 10.

 policy-statement change-pref {          from next-hop 10.0.0.1;         to area 0.0.0.3;         then {             preference 10;         }     } 

Match conditions can be also specified using route filters. Route filtering is a method of picking out a route or specific routes from the routing table and performing a common action on them. Route filtering will be examined in greater detail later in this chapter.