Juniper Routing Policy and Firewall Filters

This chapter is from the book

Juniper Networks Field Guide and Reference

Learn More Buy

This chapter is from the book

This chapter is from the book 

Juniper Networks Field Guide and Reference

Learn More Buy

Configuring Routing Policy

To configure routing policy, you first define the policy, then apply it to a routing protocol or the forwarding table.

Defining Routing Policies

To define a routing policy, include the policy-statement statement. Each routing policy name must be unique within a configuration.

[edit policy-options]
policy-statement policy-name {
	term term-name {
		from {
			match-conditions ;
			policy subroutine-policy-name ;
			prefix-list name;
			route-filter destination-prefix match-type <actions>;
			source-address-filter destination-prefix match-type <actions > ;
		}
		to {
			match-conditions ;
			policy subroutine-policy-name ;
		}
		then actions ;
		prefix-list name {
		ip-addresses ;
	}
}

Each policy term can consist of two statements, from and to, that define match conditions. In the from statement, define the criteria that an incoming route must match. You can specify one or more match conditions. If you specify more than one, they all must match the route for a match to occur. The from statement is optional. If you omit it and the to statement, all routes are considered to match. In export policies, omitting the from statement in a routing policy term might lead to unexpected results. In the to statement, define the criteria that an outgoing route must match. You can specify one or more match conditions. If you specify more than one, they all must match the route for a match to occur. You can specify most of the same match conditions in the to statement as in the from statement. In most cases, specifying a match condition in the to statement produces the same result as specifying the same match condition in the from statement. The to statement is optional. If you omit both it and the from statement, all routes are considered to match.

All conditions in the from and to statements must match for the action to be taken. The match conditions are effectively a logical AND operation. Table 8.7 describes the match conditions for incoming and outgoing routes. This table indicates whether the match condition is standard or extended. In general, 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.

Table 8.7 Routing Policy Match Conditions

Each policy term can include a then statement, which defines the actions to take if a route matches all the conditions in the from and to statements. If a term does not have from and to statements, all routes are considered to match and the actions apply to them all. The then statement is optional. You can specify one or more actions. There are three types of actions: flow control actions (see Table 8.8), which affect whether to accept or reject the route and whether to evaluate the next term or routing policy, actions that manipulate route characteristics (see Table 8.9), and trace action, which logs route matches.

If you do not include a then statement, the next term in the routing policy, if one is present, is evaluated; if there are no more terms in the routing policy, the next routing policy, if one is present, is evaluated; or if there are no more terms or routing policies, the accept or reject action specified by the default policy is taken.

Table 8.8 Flow Control Actions

Table 8.9 Actions That Manipulate Route Characteristics

Applying Routing Policies

For a routing policy to take effect, you must apply it to either a routing protocol or the forwarding table. To apply a routing policy to a routing protocol, include the import and export statements:

[edit protocols protocol-name]
import policy-name ;
export policy-name ; 

In the import statement, list the name of the routing policy to be evaluated when routes are imported into the routing table from the routing protocol. In the export statement, list the name of the routing policy to be evaluated when routes are being exported from the routing table into a dynamic routing protocol. Only active routes are exported from the routing table.

To apply multiple routing policies (chains) to a routing protocol, include the import and export statements at the [edit protocols protocol-name] hierarchy level:

[edit protocols protocol-name]
import [ policy-name policy-name ... ]
export [ policy-name policy-name ... ] 

In the import statement, list the names of multiple routing policies to be evaluated when routes are imported into the routing table from the routing protocol. In the export statement, list the names of multiple routing policies to be evaluated when routes are being exported from the routing table into a dynamic routing protocol. Only active routes are exported from the routing table.

The policy framework software evaluates the routing policies sequentially, from left to right. If an action specified in one of the policies manipulates a route characteristic, the policy framework software carries the new route characteristic forward during the evaluation of the remaining policies. For example, if the action specified in the first policy of a chain sets a route's metric to 500, this route matches the criterion of metric 500 defined in the next policy.

The policy framework software can evaluate routing policies using policy expressions, which use Boolean logical operators with policies. The logical operators establish rules by which the policies are evaluated. During evaluation of a routing policy in a policy expression, the policy actions of accept, reject, or next policy are converted to the value of TRUE or FALSE. This value is then evaluated against the logic of the specified logical operator to produce output of either TRUE or FALSE. The output is then converted back to a flow control action of accept, reject, or next policy. The result of the policy expression is applied in the same manner as it would be applied to a single policy; that is, the route is accepted or rejected and the evaluation ends, or the next policy is evaluated. Table 8.10 summarizes the policy actions and their corresponding TRUE and FALSE values and flow control action values. Table 8.11 describes the logical operators. You can place a policy expression anywhere in the import or export statements and in the from policy statement, enclosing the expression in parentheses.

Table 8.10 Policy Action Conversion Values

Table 8.11 Policy Expression Logical Operators

The policy framework software evaluates a policy expression as follows:

1. The software evaluates a route against the first routing policy in a policy expression and converts the specified or default action to a value of TRUE or FALSE.

2. The software takes the value of TRUE or FALSE and evaluates it against the logical operator used in the policy expression. Based on the logical operator used, the software determines whether to evaluate the next routing policy, if one is present.

   The policy framework software uses a method of shortcut evaluation. When a result is certain, the software stops evaluating subsequent routing policies in the policy expression. For example, if the policy expression specifies logical AND and the evaluation of the first routing policy returns the value of FALSE, the software determines that the output will be FALSE no matter what the value of the unevaluated routing policies are. Therefore, the software does not evaluate the subsequent routing policies in this policy expression.

3. The software performs the same tasks described in Steps 1 and 2 for each subsequent routing policy in the policy expression, if they are present and if the software has determined that it is appropriate to evaluate them.

4. After evaluating the last routing policy, if it is appropriate, the software evaluates the value of TRUE or FALSE obtained from each routing policy evaluation. Based on the logical operator used, it calculates an output of TRUE or FALSE.

5. The software converts the output of TRUE or FALSE back to an action, and the action is performed.

   In cases where each policy in the expression returned a value of TRUE, the software converts the output of TRUE back to the flow control action specified in the last policy. For example, if the policy expression (policy1 && policy2) is specified and policy1 specifies accept and policy2 specifies next term, the next term action is performed.

If an action specified in one of the policies manipulates a route characteristic, the policy framework software carries the new route characteristic forward during the evaluation of the remaining policies. For example, if the action specified in the first policy of a policy expression sets a route's metric to 500, this route matches the criteria of metric 500 defined in the next policy. However, if a route characteristic manipulation action is specified in a policy located in the middle or the end of a policy expression, it is possible, because of the shortcut evaluation, that the policy is never evaluated and the manipulation of the route characteristic never occurs.

Applying Routing Policies to the Forwarding Table

To apply an export routing policy to the forwarding table for per-packet load balancing and CoS, include the forwarding-table statement:

[edit routing-options]
forwarding-table {
	export [ policy-name ];
}

Configuring AS Path Regular Expressions

A BGP AS path is a path to a destination. To define a match condition based on all or portions of the AS path, first define the AS path in the as-path statement:

[edit policy-options]
as-path name regular-expression ; 

Then, name the AS path regular expression in a routing policy, including the as-path match condition in the from statement:

[edit policy-options]
policy-statement policy-name {
	term term-name {
		from {
			as-path names;
		}
	}
}

The regular expression, which is used to match all or portions of the AS path, consists of two components, which you specify in the following format:

term <operator >

The term identifies an AS. You can specify it in one of the following ways:

• AS number—The entire AS number composes one term. You cannot reference individual characters within an AS number, which differs from regular expressions as defined in POSIX 1003.2.

• Wildcard character—Matches any single AS number. The wildcard character is a period (.). You can specify multiple wildcard characters.

• AS path—A single AS number or a group of AS numbers enclosed in parentheses. Grouping the regular expression in this way allows you to perform a common operation on the group as a whole and to give the group precedence. The grouped path can itself include operators.

The optional operator defines pattern matching operations to apply to the term. You define the operations using regular expressions. Table 8.12 lists the regular expression operators supported for AS paths. You place operators immediately after term with no intervening space, except for the pipe ( | ) and dash (–) operators, which you place between two terms, and parentheses, with which you enclose terms.

Table 8.12 AS Path and Community Attribute and Regular Expressions Operators

AS path regular expressions implement the extended (modern) regular expressions as defined in POSIX 1003.2 They are identical to the UNIX regular expressions with the following exceptions:

• The basic unit of matching in an AS path regular expression is the AS number, not an individual character.

• A regular expression matches a route only if the AS path in the route exactly matches regular-expression. The equivalent UNIX regular expression is ^regular-expression $. For example, the AS path regular expression 1234 is equivalent to the UNIX regular expression ^1234$.

• You can specify a regular expression using wildcard operators.

Configuring Communities

A BGP community is a group of destinations that share a common property. Community information is included as a path attribute in BGP update messages and identifies community members and allows you to perform actions on a group without having to elaborate on each member. You can define match conditions based on a BGP community, which this section describes. You can assign community tags to non-BGP routes through configuration (for static, aggregate, or generated routes) or an import routing policy. These tags can then be matched when BGP exports the routes.

To create a named community and define the community members, include the community statement:

[edit policy-options]
community name members [ community-ids ];

Then, name the community in a routing policy, including the community condition in the from statement. If you include the names of multiple communities, only one community need match for a match to occur.

[edit policy-options]
policy-statement policy-name {
	term term-name {
		from {
			community names;
		}
	}
}

name identifies the community or communities. It can contain letters, numbers, and hyphens (-), and can be up to 255 characters long. To include spaces in the name, enclose the entire name in quotation marks (double quotes).

Specify the community identifier in the following format:

as-number :community-value

The AS number of the community member can be a value from 1 through 65,534. The community value can be a number from 0 through 65,535. You can specify these numbers in one of the following ways:

• AS number.

• Asterisk (*)—A wildcard character that matches all AS numbers. (In the definition of the community attribute, the asterisk also functions as described in Table 8.12.)

• Period (.)—A wildcard character that matches any single digit in an AS number.

• Group of numbers—A single AS or community number or a group of numbers enclosed in parentheses. Grouping the numbers in this way allows you to perform a common operation on the group as a whole and to give the group precedence. The grouped numbers can themselves include regular expression operators.

You also can specify the community identifier as one of the following well-known community names, which are defined in RFC 1997:

• no-advertise—Routes in this community name must not be advertised to other BGP peers.

• no-export—Routes in this community must not be advertised outside a BGP confederation boundary.

• no-export-subconfed—Routes in this community must not be advertised to external BGP peers, including peers in other members' ASs inside a BGP confederation.

When specifying community identifiers, you can use UNIX-style regular expressions to specify the AS number and the member identifier. A regular expression consists of two components, which you specify in the following format:

term <operator > 

term identifies the string to match. operator defines pattern-matching operations to apply to the term. Table 8.12 lists the regular expression operators supported for the community attribute. You place an operator immediately after term with no intervening space, except for the pipe ( | ) and dash (–) operators, which you place between two terms, and parentheses, with which you enclose terms.

Community regular expressions are identical to the UNIX regular expressions. Both implement the extended (or modern) regular expressions as defined in POSIX 1003.2. Community regular expressions evaluate the string specified in the term on a character-by-character basis. For example, if you specify 1234:5678 as the term, the regular expressions see nine discrete characters, including the colon (:), instead of two sets of numbers (1234 and 5678) separated by a colon.

By default, communities are sent to BGP peers. To suppress the advertisement of communities to a neighbor, remove all communities by defining a wildcard set of communities (here, the community is named wild) and then specifying the community delete action. When the result of an export policy is an empty set of communities, the community attribute is not sent.

[ edit policy-options ]
community wild members " * : * " ;
policy-statement policy-name {
	term term-name {
		then community delete wild;
	}
}

To configure extended communities, define the community and then reference it in the from statement:

[edit policy-options]
community name members [ community-ids ] ;
policy-statement policy-name {
	term term-name {
		from {
			community name;
		}
	}
}

The community identifier is the type of extended community in the following format:

type:administrator:assigned-number

type is the type of extended community and can be either a target, origin, or domain-id community. The target community identifies the destination to which the route is going. The origin community identifies where the route originated. The domain-id community identifies the OSPF domain from which the route originated. administrator is the administrator. It is either an AS number or an IPv4 address prefix, depending on the type of extended community. assigned-number identifies the local provider. Note that regular expressions are not supported for extended communities.

The policy framework software evaluates communities as follows:

• Each route is evaluated against each named community in a routing policy from statement. If a route matches one of the named communities in the from statement, the evaluation of the current term continues. If a route does not match, the evaluation of the current term ends.

• The route is evaluated against each member of a named community. The evaluation of all members must be successful for the named community evaluation to be successful.

• Each member in a named community is either a literal community value or a regular expression (applies to community attributes only). Each member is evaluated against each community on the route. (Communities are an unordered property on a route. For example, 1:2 3:4 is the same as 3:4 1:2.) Only one community from the route must match for the member evaluation to be successful.

• Community regular expressions evaluate the string specified in the term on a character-by-character basis. For example, if you specify 1234:5678 as the term, the regular expressions see nine discrete characters, including the colon (:), instead of two sets of numbers (1234 and 5678) separated by a colon. For example:

  [edit]
   policy-options {
   	policy-statement one {
   		from {
   			community [ comm-one comm-two ];
   		}
   	}
   	community members comm-one [ 1:2 "^4:(5|6)$" ];
   	community members comm-two [ 7:8 9:10 ];
   }

  To match routing policy one, the route must match either comm-one or comm-two. To match comm-one, the route must have a community that matches 1:2 and a community that matches 4:5 or 4:6. To match comm-two, the route must have a community that matches 7:8 and a community that matches 9:10.

Configuring Prefix Lists and Route Lists

A prefix list is a named list of IP addresses. You can specify an exact match with incoming routes and apply a common action to all matching prefixes in the list. A route list is a collection of destination prefixes on which a common policy action is performed. In a prefix, you can specify an exact match with a particular route or a less precise match.

A prefix list functions similarly to a route list that contains multiple instances of the exact match type only. While some functional similarities exist between these two extended match conditions, so do some important differences, which are summarized in Table 8.13.

Table 8.13 Prefix List and Route List Differences

To create a named prefix list, include the prefix-list statement, specifying one or more addresses:

[edit policy-options]
prefix-list name {
	ip-addresses;
} 

To include a prefix list in a routing policy, include the prefix-list match condition in the from statement, specifying the name of the prefix list:

[edit policy-options]
policy-statement policy-name {
	term term-name {
		from {
			prefix-list name;
		}
		then actions ;
	}
}

During prefix list evaluation, the policy framework software performs a longest-match lookup, which means that the software searches for the prefix in the list with the longest length. (Because the policy framework software scans a list looking for the longest prefix, the order in which you specify the prefixes, from top to bottom, does not matter.) The software then compares a route's source address to the longest prefix. If a match occurs, the evaluation of the current term continues. If a match does not occur, the evaluation of the current term ends. If you specify multiple prefixes in the prefix list, only one prefix need match for a match to occur.

Configuring Route Lists

To configure a route list, include one or more route-filter or source-address-filter options in the from statement:

[edit policy-options]
policy-statement policy-name {
	term term-name {
		from {
			route-filter destination-prefix match-type <actions >;
			source-address-filter destination-prefix match-type <actions > ;
		}
		then actions ;
	}
}

The route-filter statement is typically used to match prefixes of any type except for multicast source addresses. The source-address-filter option is typically used to match multicast source addresses in multiprotocol BGP (MBGP) and Multicast Source Discovery Protocol (MSDP) environments.

destination-prefix is the IPv4 or IPv6 prefix specified as prefix/prefix-length. match-type is the type of match to apply to the destination prefix (see Table 8.14). actions is the action to take if the destination prefix matches.

If you specify actions in the route-filter or source-address-filter statement, they are taken immediately when a match occurs, and the then statement is not evaluated. If you specify actions in the then statement, they are taken when a match occurs and if an action is not specified in the route-filter or source-address-filter statement.

Table 8.14 Route List Match Types

During route list evaluation, the policy framework software compares each route's source address with the destination prefixes in the route list. The policy framework software first performs a longest-match lookup, which considers the prefix and prefix length only and not the match type. The following sample route list illustrates this point:

route-filter 192.168.0.0/14 upto /24;
route-filter 192.168.0.0/15 exact;

Here, the longest prefix is 192.168.0.0/15, which is based on prefix and prefix length only. Then, if the prefix of an incoming route matches the longest prefix, the software then examines the match type and action associated with the longest prefix. If a match occurs, the action specified with the prefix is taken. If an action is not specified with the prefix, the action in the then statement is taken. If neither action is specified, the software evaluates the next term or routing policy if present or takes the accept or reject action specified by the default policy. If you specify multiple prefixes in the route list, only one prefix need match for a match to occur. If a match does not occur, the software evaluates the next term or routing policy if present or takes the accept or reject action specified by the default policy.

The order in which you specify the prefixes typically does not matter, because the policy framework software scans the route list looking for the longest prefix during evaluation. An exception to this rule is when you use the same destination prefix multiple times in a list. Here, the order is important, because the list of identical prefixes is scanned from top to bottom and the first match type that matches the route applies. In the following example, different match types are specified for the same prefix. The route 0.0.0.0/0 would be rejected, the route 0.0.0.0/8 would be marked with next-hop self, and the route 0.0.0.0/25 would be rejected.

route-filter 0.0.0.0/0 upto /7 reject;
route-filter 0.0.0.0/0 upto /24 next-hop self;
route-filter 0.0.0.0/0 orlonger reject;

A common problem when defining a route list is including a shorter prefix that you want to match with a longer, similar prefix in the same list. For example, imagine that the prefix 192.168.254.0/24 is compared against the following route list:

route-filter 192.168.0.0/16 orlonger;
route-filter 192.168.254.0/23 exact;

Because of the longest-match lookup, the prefix 192.168.254.0/23 is determined to be the longest prefix. An exact match does not occur between 192.168.254.0/24 and 192.168.254.0/23 exact, so the software concludes that the term does not match and goes on to the next term or routing policy if present or takes the accept or reject action specified by the default policy. The shorter prefix 192.168.0.0/16 orlonger that you wanted to match is inadvertently ignored. One solution is to remove the prefix 192.168.0.0/16 orlonger from the route list in this term and move it to a previous term in which it is the only prefix or the longest prefix in the list.

Configuring Subroutines

Using a routing policy called from another routing policy as a match condition makes the called policy a subroutine. To configure a subroutine, create the subroutine and specify its name using the policy match condition in the from or to statement of another routing policy:

[edit policy-options]
policy-statement subroutine-policy-name {
	term term-name {
		from {
			match-conditions ;
			route-filter destination-prefix match-type <actions>;
			source-address-filter destination-prefix match-type <actions > ;
			prefix-list name;
		}
		to {
			match-conditions ;
		}
		then actions ;
	}
}
policy-statement policy-name {
	term term-name {
		from {
			policy subroutine-policy-name ;

		to {
			policy subroutine-policy-name ;
		}
		then actions;
	}
}

The action specified in a subroutine is used to provide a match condition to the calling policy. If the subroutine specifies an action of accept, the calling policy considers the route to be a match. If the subroutine specifies an action of reject, the calling policy considers the route to not match. If the subroutine specifies an action that is meant to manipulate the route characteristics, the changes are made.

Configuring the AS Path Prepend Action

To prepend, or add, one or more AS numbers at the beginning of an AS path, specify the as-path-prepend action in the then statement. The AS numbers are added after the local AS number has been added to the path. Prepending an AS path makes a shorter AS path look longer and therefore less preferable to BGP.

[edit policy-options]
policy-statement name {
	term name {
		from {
			route-filter destination-prefix match-type <actions>;
		}
		then as-path-prepend "as-path";
	}
}

Configuring BGP Route Flap Damping

BGP route flapping is the situation in which BGP systems send an excessive number of update messages to advertise network reachability information. BGP flap damping is a way to reduce the number of update messages sent between BGP peers, thereby reducing the load on these peers without adversely affecting the route convergence time. Flap damping reduces the number of update messages by marking routes as ineligible for selection as the active or preferable route. Doing this leads to some delay, or suppression, in the propagation of route information, but the result is increased network stability.

To effect changes to the default BGP flap damping values, include the following statements. Table 8.15 describes the damping parameters.

[edit policy-options]
damping name {
	disable;
	half-life minutes ;
	max-suppress minutes ;
	reuse number ;
	suppress number ;
}
policy-statement name {
	term name {
		from {
			...
		}
		then damping name;
	}
} 

Table 8.15 Damping Parameters

Configuring Per-Packet Load Balancing

For the active route, when there are multiple equal-cost paths to the same destination, by default, the JUNOS software chooses in a random fashion one of the next-hop addresses to install into the forwarding table. Whenever the set of next hops for a destination changes in any way, the next-hop address is rechosen, also in a random fashion. You can configure the JUNOS software so that, for the active route, all next-hop addresses for a destination are installed in the forwarding table, a process called per-packet load balancing. You can use load balancing to spread traffic across multiple paths between routers.

On routers with the Internet Processor II ASIC, when per-packet load balancing is configured, traffic between routers with multiple paths is divided into individual traffic flows (up to 16 equal-cost load-balanced paths). Packets for each individual flow are kept on a single interface. To recognize individual flows in the transit traffic, the router examines the source IP address, destination IP address, and protocol.

The router recognizes packets that have all these parameters identical, and it ensures that these packets are sent out through the same interface. This prevents problems that might otherwise occur with packets arriving at their destination out of their original sequence.

To configure per-packet load balancing, you configure the load-balance per-packet action and apply the routing policy to the forwarding table by including the export statement at the [edit routing-options forwarding-table] hierarchy level.