| 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 | Match Condition | Match Condition Category | from Statement Description | to Statement Description | | area area-id | Standard | (OSPF only) Area identifier. In a from statement used with an export policy, match a route learned from the specified OSPF area when exporting OSPF routes into other protocols. | | as-path name | Extended | (BGP only) Name of an AS path regular expression. | color preference color2 preference | Standard | Color value, for preference values ( color and color2 ) that are finer-grained than those specified in the preference and preference2 match conditions. The color value can be a number in the range 0 through 4,294,967,295 (2 32 1), with a lower number indicating a more-preferred route. For more information about preference values, see Table 9.1, "Default Route Preference Values," on page 379. | | community [ names ] | Extended | Name of one or more communities. If you list more than one name, only one name needs to match for a match to occur. The community matching is effectively a logical OR operation. | | external [type metric-type ] | Standard | (OSPF only) External routes, including routes exported from one level to another. type is an optional keyword. metric can either be 1 or 2. When you do not specify type , this condition matches all external routes. When you specify type , this condition matches only OSPF routes with the specified OSPF metric type. | | family family-name | Standard | Name of an address family. family-name can be either inet or inet6 . Match the address family (IPv4 or IPv6) of the route. | | instance instance-name | Standard | Routing instance or instances specified by name. Match a route learned from one of the specified instances. | Routing instance or instances specified by name. Match a route to be advertised over one of the specified instances. | | interface interface-name | Standard | Router interface or interfaces specified by name or IP address. Do not use this qualifier with protocols that are not interface specific, such as IBGP. Match a route learned from one of the specified interfaces. Direct routes match routes configured on the specified interface. | Router interface or interfaces specified by name or IP address. Do not use this qualifier with protocols that are not interface specific, such as IBGP. Match a route to be advertised from one of the specified interfaces. | | level level | Standard | (IS-IS only) IS-IS level. Match a route learned from a specified level. | (IS-IS only) IS-IS level. Match a route to be advertised to a specified level. | | local-preference value | Standard | (BGP only) BGP local preference ( LOCAL_PREF ) attribute. The value can be a number in the range 0 through 4,294,967,295 (2 32 1). | metric metric metric2 metric metric3 metric metric4 metric | Standard | Metric value. You can specify up to four metric values, starting with metric (for the first metric value) and continuing with metric2 , metric3 , and metric4 . (BGP only) metric corresponds to the MED, and metric2 corresponds to the IGP metric if the BGP next hop runs back through another route. | | neighbor address | Standard | Neighbor (peer) address or addresses. For BGP, the address can be a directly connected or indirectly connected peer. For all other protocols, the address is the neighbor from which the advertisement is received. | Neighbor (peer) address or addresses. For BGP import policies, specifying to neighbor produces the same result as specifying from neighbor . For BGP export policies, specifying the neighbor match condition has no effect and is ignored. For all other protocols, the to statement matches the neighbor to which the advertisement is sent. | | next-hop address | Standard | Next-hop address or addresses specified in the routing information for a particular route. | | origin value | Standard | (BGP only) BGP origin attribute, which is the origin of the AS path information. The value can be one of the following: -
egp Path information originated in another AS. -
igp Path information originated within the local AS. -
incomplete Path information was learned by some other means. | | policy [ policy-name ] | Extended | Name of a policy to evaluate as a subroutine. | preference preference preference2 preference | Standard | Preference value. You can specify a primary preference value ( preference ) and a secondary preference value ( preference2 ). The value can be a number in the range 0 through 4,294,967,295 (2 32 1), with a lower number indicating a more-preferred route. To specify even finer-grained preference values, see the color and color2 match conditions in this table. For more information about preference values, see Table 9.1, "Default Route Preference Values," on page 379. | | prefix-list name ip-addresses | Extended | Named list of IP addresses. You can specify an exact match with incoming routes. | You cannot specify this match condition. | | protocol protocol | Standard | Name of the protocol from which the route was learned or to which the route is being advertised. It can be one of the following: aggregate , bgp , direct , dvmrp , isis , local , ospf , pim-dense , pim-sparse , rip , ripng , or static . | | rib routing-table | Standard | Name of a routing table. It can be one of the following: -
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. | route-filter destination-prefix match-type <actions> | Extended | List of destination prefixes. When specifying a destination prefix, you can specify an exact match with a specific route or a less precise match using match types. You can configure either a common action that applies to the entire list or an action associated with each prefix. | You cannot specify this match condition. | source-address-filter destination-prefix match-type < actions > | Extended | List of multicast source addresses. When specifying a source address, you can specify an exact match with a specific route or a less precise match using match types. You can configure either a common action that applies to the entire list or an action associated with each prefix. | You cannot specify this match condition. | tag string tag2 string | Standard | You can specify two tag strings: tag (for the first string) and tag2 . These values are local to the router and can be set on configured routes or by using an import routing policy. | 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 | Flow Control Action | Description | | accept | Accept the route and propagate it. After a route is accepted, no other terms in the routing policy and no other routing policies are evaluated. | | reject | Reject the route and do not propagate it. After a route is rejected, no other terms in the routing policy and no other routing policies are evaluated. | | next term | Skip to and evaluate the next term in the same routing policy. Any accept or reject action specified in the then statement is skipped . Any actions in the then statement that manipulate route characteristics are applied to the route. next term is the default control action if a match occurs and if you do not specify a flow control action. | | next policy | Skip to and evaluate the next routing policy. Any accept or reject action specified in the then statement is skipped. Any actions in the then statement that manipulate route characteristics are applied to the route. next policy is the default control action if a match occurs, if you do not specify a flow control action, and if there are no further terms in the current routing policy. | Table 8.9. Actions That Manipulate Route Characteristics | Action | Description | | as-path-prepend as-path | (BGP only) Affix one or more AS numbers at the beginning of the AS path. To specify more than one AS number, include the numbers in quotation marks. The AS numbers are added after the local AS number has been added to the path. This action adds AS numbers to AS sequences only, not AS sets. If the existing AS path begins with a confederation sequence or set, the affixed AS numbers are placed within a confederation sequence. Otherwise , the affixed AS numbers are placed with a nonconfederation sequence. | as-path-expand last-as count n | (BGP only) Extract the last AS number in the existing AS path and affix that AS number to the beginning of the AS path n times, where n is from 1 through 32. The AS number is added before the local AS number has been added to the path. This action adds AS numbers to AS sequences only. AS sets are ignored. If the existing AS path begins with a confederation sequence or set, the affixed AS numbers are placed within a confederation sequence. Otherwise, the affixed AS numbers are placed with a nonconfederation sequence. This option is typically used in EBGP export policies. | | class class-name | (CoS only) Apply parameters to routes installed into the routing table. For more information about CoS, see Chapter 6,"Interfaces and Class of Service," on page 185. | color preference color2 preference | Set the preference value to a specific value. The color and color2 preference values are even finer-grained than those specified in the preference and preference2 actions. The color value can be a number in the range 0 through 4,294,967,295 (2 32 1), with a lower number indicating a more-preferred route. If you set the preference with the color action, the value is internal to the JUNOS software and is not transitive. For more information about preference values, see Table 9.1, "Default Route Preference Values," on page 379. | color (add subtract) number color2 (add subtract) number | Change the color preference value by the specified amount. If an addition operation results in a value that is greater than 4,294,967,295 (2 32 1), the value is set to 2 32 1. If a subtraction operation results in a value less than 0, the value is set to 0. If no attribute value is set before the addition or subtraction operation, the attribute value defaults to 0. If you perform an addition to an attribute with a value of 0, that number becomes the constant value. | | community (+ add) [ names ] | (BGP only) Add communities to the set of communities in the route. | | community ( delete) [ names ] | (BGP only) Delete communities from the set of communities in the route. | | community (= set) [ names ] | (BGP only) Set the communities in the route, replacing any communities that were in the route. | | damping name | (BGP only) Apply route-damping parameters to the route. These parameters override the default damping parameters. This action is useful only in an import policy, because the damping parameters affect the state of routes in the routing table. To apply damping parameters, you must enable BGP flap damping as described in "Configuring Route Flap Damping," on page 406, and you must create a named list of parameters. | destination-class destination-class-name | Maintain packet counts for a route passing through your network based on the ingress and egress points. To configure, group destination prefixes by configuring a routing policy. Enable packet counting on one or more interfaces by including the destination-class-usage statement at the [edit interfaces interface-name unit logical-unit-number family inet] hierarchy level, then apply that routing policy to the forwarding table with the corresponding destination class. | | external type metric | Set the external metric type for routes exported by OSPF. You must specify the keyword type . | install-nexthop lsp lsp-name | Choose which, among a set of equal-cost label-switched path (LSP) next hops, are installed in the forwarding table. To choose, use the export policy for the forwarding table to specify the LSP next hop to be used for the desired routes. | load-balance per-packet | (For export to the forwarding table only) Install all next-hop addresses into the forwarding table and have the forwarding table perform per-packet load balancing. | | local-preference value | (BGP only) Set the BGP local preference ( LOCAL_PREF ) attribute. The preference value can be a number in the range 0 through 4,294,967,295. | local-preference (add subtract) number | Change the local preference value by the specified amount. If an addition operation results in a value that is greater than 4,294,967,295 (2 32 1), the value is set to 2 32 1. If a subtraction operation results in a value less than 0, the value is set to 0. If no attribute value is set before the addition or subtraction operation, the attribute value defaults to 0. If you perform an addition to an attribute with a value of 0, that number becomes the constant value. For BGP, if the attribute value is not known, the local preference attribute value is initialized to 100 before the routing policy is applied. | metric metric metric2 metric metric3 metric metric4 metric | Set the metric. You can specify up to four metric values, starting with metric (for the first metric value) and continuing with metric2 , metric3 , and metric4 . (BGP only) metric corresponds to the multiple exit discriminator (MED), and metric2 corresponds to the IGP metric if the BGP next hop recourses through another router. | metric (add subtract) number metric2 (add subtract) number metric3 (add subtract) number metric4 (add subtract) number | Change the metric value by the specified amount. If an addition operation results in a value that is greater than 4,294,967,295 (2 32 1), the value is set to 2 32 1. If a subtraction operation results in a value less than 0, the value is set to 0. If no attribute value is set before the addition or subtraction operation, the attribute value defaults to 0. If you perform an addition to an attribute with a value of 0, that number becomes the constant value. | | metric (igp minimum-igp) site-offset | (BGP only) Change the MED value by the specified negative or positive offset. This action is useful only in an EBGP export policy. | | next-hop (address peer-address) | Set the next hop. When the advertising protocol is BGP, you can set the next hop only when any third-party next hop can be advertised; that is, when using IBGP or EBGP confederations. If you specify address as self , the next-hop address is replaced by one of the local router's addresses. The advertising protocol determines which address to use. When the advertising protocol is BGP, this address is set to the local IP address used for the BGP adjacency . A router cannot install routes with itself as the next hop. If you specify peer-address , the next-hop address is replaced by the peer's IP address. This option is only valid in import policies. Primarily used by BGP to enforce using the peer's IP address for advertised routes, this option is only meaningful when the next hop is the advertising router or another directly connected router. | | origin value | (BGP only) Set the BGP origin attribute to one of the following values: -
igp Path information originated within the local AS. -
egp Path information originated in another AS. -
incomplete Path information was learned by some other means. | preference preference preference2 preference | Set the preference value. You can specify a primary preference value ( preference ) and a secondary preference value ( preference2 ). The preference value can be a number in the range 0 through 4,294,967,295 (2 32 1), with a lower number indicating a more-preferred route. To specify even finer-grained preference values, see the color and color2 actions in this table. If you set the preference with the preference action, the new preference remains associated with the route. The new preference is internal to the JUNOS software and is not transitive. For more information about preference values, see the Table 9.1, "Default Route Preference Values," on page 379. | preference (add subtract) number preference2 (add subtract) number | Change the preference value by the specified amount. If an addition operation results in a value that is greater than 4,294,967,295 (2 32 1), the value is set to 2 32 1. If a subtraction operation results in a value less than 0, the value is set to 0. If no attribute value is set before the addition or subtraction operation, the attribute value defaults to 0. If you perform an addition to an attribute with a value of 0, that number becomes the constant value. | tag tag tag2 tag | You can specify two tag strings: tag (for the first string) and tag2 . These values are local to the router. For OSPF only, the tag and tag2 actions set the 32-bit tag field in OSPF external LSA packets. | tag (add subtract) number tag2 (add subtract) number | Change the tag value by the specified amount. If an addition operation results in a value that is greater than 4,294,967,295 (2 32 1), the value is set to 2 32 1. If a subtraction operation results in a value less than 0, the value is set to 0. If no attribute value is set before the addition or subtraction operation, the attribute value defaults to 0. If you perform an addition to an attribute with a value of 0, that number becomes the constant value. | 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 | Policy Action | Conversion Value | Flow Control Action Conversion Value | | accept | TRUE | accept | | reject | FALSE | reject | | next policy | TRUE | next policy | Table 8.11. Policy Expression Logical Operators | Logical Operator | Policy Expression Logic | How Logical Operator Affects Policy Expression Evaluation | | && (Logical AND) | Logical AND requires that all values must be TRUE to produce output of TRUE. Routing policy value of TRUE and TRUE produces output of TRUE. Value of TRUE and FALSE produces output of FALSE. Value of FALSE and FALSE produces output of FALSE. | If the first routing policy returns the value of TRUE, the next policy is evaluated. If the first policy returns the value of FALSE, the evaluation of the expression ends and subsequent policies in the expression are not evaluated. | | (Logical OR) | Logical OR requires that at least one value must be TRUE to produce output of TRUE. Routing policy value of TRUE and FALSE produces output of TRUE. Value of TRUE and TRUE produces output of TRUE. Value of FALSE and FALSE produces output of FALSE. | If the first routing policy returns the value of TRUE, the evaluation of the expression ends and subsequent policies in the expression are not evaluated. If the first policy returns the value of FALSE, the next policy is evaluated. | | ! (Logical NOT) | Logical NOT reverses value of TRUE to FALSE and of FALSE to TRUE. Also reverses the actions of accept and next policy to reject, and reject to accept. | If used with the logical AND operator and the first routing policy value of FALSE is reversed to TRUE, the next policy is evaluated. If the value of TRUE is reversed to FALSE, the evaluation of the expression ends and subsequent policies in the expression are not evaluated. If used with the logical OR operator and the first routing policy value of FALSE is reversed to TRUE, the evaluation of the expression ends and subsequent policies in the expression are not evaluated. If the value of TRUE is reversed to FALSE, the next policy is evaluated. If used with a policy and the flow control action is accept or next policy, these actions are reversed to reject. If the flow control action is reject , this action is reversed to accept . | The policy framework software evaluates a policy expression as follows : -
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. -
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. -
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. -
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. -
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 numberThe 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 characterMatches any single AS number. The wildcard character is a period (.). You can specify multiple wildcard characters. -
AS pathA 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. | You can specify one or more termoperator pairs in a single regular expression. | 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 | Operator | Match | | { m,n } | At least m and at most n repetitions of term . Both m and n must be positive integers, and m must be smaller than n . | | { m } | Exactly m repetitions of term . m must be a positive integer. | | { m ,} | m or more repetitions of term . m must be a positive integer. | | * | Zero or more repetitions of term . This is equivalent to {0,}. | | + | One or more repetitions of term . This is equivalent to {1,}. | | ? | Zero or one repetition of term . This is equivalent to {0,1}. | | | One of the two terms on either side of the pipe. | | | Between a starting and ending range, inclusive. | | ^ | Character at the beginning of an AS path regular expression. This character is added implicitly; therefore, the use of it is optional. | | $ | Character at the end of an AS path regular expression. This character is added implicitly; therefore, its use is optional. | | () | A group of terms that are enclosed in the parentheses. If enclosed in quotation marks with no intervening space ("()"), indicates a null. Intervening space between the parentheses and the terms is ignored. | | [ ] | Set of characters. One character from the set can match. To specify the start and end of a range, use a dash (). | 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 numbersA 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:(56)$" ]; 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 | Feature | Prefix List | Route Lists | | Match types | Does not support match types. The specified prefixes must be matched exactly. | Supports several match types. For more information, see Table 8.14 on page 347. | | Action | Can specify action in a then statement only. This action is applied to all prefixes in the list. | Can specify action that is applied to a particular prefix in a route-filter match condition in a from statement or to all prefixes in the list using a then statement. | 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. | For a list of actions, see Table 8.8 and Table 8.9 on page 331. | 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. 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. Table 8.14. Route List Match Types | Match Type | Match If | | exact | Route shares the same most-significant bits (described by prefix-length ) and prefix-length is equal to the route's prefix length. | | longer | Route shares the same most-significant bits (described by prefix-length ) and prefix-length is greater than the route's prefix length. | | orlonger | Route shares the same most-significant bits (described by prefix-length ) and prefix-length is equal to or greater than the route's prefix length. | prefix-length-range prefix-length2 prefix-length3 | Route shares the same most-significant bits (described by prefix-length ) and the route's prefix length falls between prefix-length2 prefix-length3 , inclusive. The upto and prefix-length-range match types are similar in that both specify the most significant bits and provide a range of prefix lengths that can match. The difference is that upto allows you to specify an upper limit only for the prefix length range, whereas prefix-length-range allows you to specify both lower and upper limits. | | through destination-prefix | Matches all the following: -
Route shares the same most-significant bits (described by prefix-length ) of the first destination prefix. -
Route shares the same most-significant bits (described by prefix-length ) of the second destination prefix for the number of bits in the prefix length. -
Number of bits in the route's prefix length is less than or equal to the number of bits in the second prefix. You do not use the through match type in most routing policy configurations. | | upto prefix-length2 | Route shares the same most-significant bits (described by prefix-length ) and the route's prefix length falls between prefix-length and prefix-length2 . | 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; } } | Do not evaluate a routing policy within itself. If you attempt to do so, no prefixes will ever match the routing policy. | 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 flap damping is defined in RFC 2439, 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 apply the changes in BGP, see "Configuring Route Flap Damping," on page 406. | 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 | Damping Parameter | Description | Default | Possible Values | | half-life minutes | Decay half-life, in minutes | 15 minutes | 1 through 45 minutes | | max-suppress minutes | Maximum hold-down time, in minutes | 60 minutes | 1 through 720 minutes | | reuse number | Reuse threshold | 750 (unitless) | 1 through 20,000 (unitless) | | suppress number | Cutoff (suppression) threshold | 3,000 (unitless) | 1 through 20,000 (unitless) | 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. | For information on this action, see Table 8.9 on page 331. | To configure per-packet load balancing, you configure the l oad-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.  |
