Routing policies

A match condition in a routing policy can call another routing policy as a subroutine.

SR Linux supports up to three levels of policy subroutines. For example, a main policy P₀ can call a P₁ policy. The P₁ policy can call a P₂ policy, and the P₂ policy can call a P₃ policy.

A route that is accepted by a P_n subroutine policy matches the P_n-1 policy statement that called policy P_n.

The subroutine policies (P₁-P₃) can modify the attributes of matched routes. These modifications can happen in statements with action accept or action next-statement or where the default-action is accept.

The subroutine policy match can be combined with other match conditions in the same statement of a policy. Logically, the subroutine is evaluated after all other match conditions in the statement.

If the subroutine policy has a statement with action next-policy or default-action next-policy, it is considered the same as reject.

If a route that does not match any terminating entry of a subroutine (that is, the route does not match any statement with an action of accept or reject or next-policy), it is considered to be accepted by the subroutine if the default-action of the subroutine policy is accept. Otherwise, the route is considered to be rejected by the subroutine.

The following example shows a routing policy P1 that uses policy P2 as a subroutine.

--{ +* candidate shared default }--[  ]--
# info with-context routing-policy
    routing-policy {
        policy P1 {
            statement 10 {
                match {
                    call-policy [
                        P2
                    ]
                    bgp {
                        as-path {
                            as-path-set downstream
                        }
                    }
                }
                action {
                    policy-result accept
                }
            }
        }
        policy p2 {
            statement 10 {
                match {
                    prefix {
                        prefix-set selected
                    }
                }
                action {
                    policy-result accept
                }
            }
        }
    }

The following describes the supported policy actions for received BGP routes based on the contents of the MED attribute in the route (if any).

When a BGP export policy matches a non-BGP route for advertisement to neighbors:

• If the route is matched by an export policy statement that applies the action bgp med set route-table-cost, then a MED attribute is added to the BGP route and its value is the route-table metric for the non-BGP route.
• If the route is matched by an export policy statement that applies the action bgp med set <number>, then a MED attribute is added to the BGP route and its value is <number>.
• If neither case applies, no MED is added to the route.

When a BGP route is received with a MED attribute:

• If the route is matched by an import policy statement that applies the action bgp med set route-table-cost, then the MED attribute is replaced and the new value is the route-table metric of the route that resolves the BGP next-hop.
• If the route is matched by an import policy statement that applies the action bgp med set <number>, then the MED attribute is replaced and the new value is <number>.
• If neither case applies, the RIB-IN MED attribute is unmodified.

When a BGP route is received without a MED attribute:

• If the route is matched by an import policy statement that applies the action bgp med set route-table-cost, then a MED attribute is added to the BGP route and the new value is the route-table metric of the route that resolves the BGP next-hop.
• If the route is matched by an import policy statement that applies the action bgp med set <number>, then a MED attribute is added to the BGP route and its value is <number>.
• If neither case applies, no MED attribute is added to the route.

When a BGP route is received with a MED attribute from one eBGP peer, and the route must be advertised to other eBGP peers:

• If the route is matched by an export policy statement that applies the action bgp med set route-table-cost, then the MED attribute is replaced and the new value is the route-table metric of the route that resolves the BGP next-hop (0 when receiving a route from a single hop eBGP peer)
• If the route is matched by an export policy statement that applies the action bgp med set <number>, then the MED attribute is replaced and the new value is <number>.
• If neither case applies, the MED is stripped.

When a BGP route is received without a MED attribute from one eBGP peer, and the route must be advertised to other eBGP peers:

• If the route is matched by an export policy statement that applies the action bgp med set route-table-cost, then a MED attribute is added to the BGP route and its value is the route-table metric of the route that resolves the BGP next-hop (0 when receiving a route from a single hop eBGP peer).
• If the route is matched by an export policy statement that applies the action bgp med set <number>, then a MED attribute is added to the BGP route and its value is <number>.
• If neither case applies, no MED is added to the route.

When a BGP route is received with a MED attribute from one eBGP peer, and the route must be advertised to iBGP peers, or else the route was received with a MED attribute from an iBGP peer for propagation to other iBGP peers:

• If the route is matched by an export policy statement that applies the action bgp med set route-table-cost, then the MED attribute is replaced and the new value is the route-table metric of the route that resolves the BGP next-hop.
• If the route is matched by an export policy statement that applies the action bgp med set <number>, then the MED attribute is replaced and the new value is <number>.
• If neither case applies, the MED is unmodified.

When a BGP route is received with a MED attribute from one eBGP/iBGP peer, and the route must be advertised to other eBGP peers, the MED is stripped by default (if the route is not matched by a policy).

When a BGP route is received without a MED attribute from one eBGP peer, and the route must be advertised to iBGP peers, or else the route was received without a MED attribute from an iBGP peer for propagation to other eBGP or iBGP peers:

• If the route is matched by an export policy statement that applies the action bgp med set route-table-cost, then a MED attribute is added to the BGP route and its value is the route-table metric of the route that resolves the BGP next-hop.
• If the route is matched by an export policy statement that applies the action bgp med set <number>, then a MED attribute is added to the BGP route and its value is <number>.
• If neither case applies, no MED is added to the route.

Some data center switches have limited IP FIB capacity. It is possible these switches could receive more BGP routes than they have room for in their IP FIB tables. In such cases, you may want to suppress the IP FIB installation of some or all of the BGP routes the switch does not require for forwarding (for example, because the switch is not in the forwarding path, as in the case of a non-next-hop-self route reflector, or because the switch can fall back to less specific routes, such as a default route).

Matching and rejecting a BGP route in a BGP import policy prevents the route from being installed in the IP FIB, but it also prevents the route from being re-advertised to other BGP peers, which could be unacceptable. For these cases, you can configure the disable-ip-route-install policy action. This policy action works as follows:

For unlabeled IPv4 and IPv6 routes matched and accepted by a BGP import policy with a disable-ip-route-install action:

• Routes are re-advertisable to other peers per normal BGP rules, even if advertise-inactive is not configured or next-hop-self is enabled.
• Routes are less preferred by the BGP decision process than any installed route for the same prefix. For these routes, fib-install-disabled is displayed as the tie-break-reason in state information.
• Routes do not contribute toward and activate a covering aggregate route.

For unlabeled IPv4 and IPv6 routes matched and accepted by a BGP import policy with a disable-ip-route-install action:

• Host routes do not create/program tunnels.
• Re-advertisement with next-hop self does create/program ILM entries.
• Routes are re-advertisable to other peers per normal BGP rules, even if advertise-inactive is not configured or next-hop-self is enabled.
• Routes are less preferred by the BGP decision process than any installed route for the same prefix. For these routes, fib-install-disabled is displayed as the tie-break-reason in state information.
• Routes do not contribute toward and activate a covering aggregate route.

BGP does not publish routes to fib_mgr that have been matched and accepted by a BGP import policy with a disable-ip-route-install action. This means they are not be re-advertisable by other protocols. In BGP RIB state information, FIB-suppressed routes display used-route false and fib-disabled true.

For IP routes that are ECMP routes (multiple next-hops), the resilient ECMP hashing feature allows changes to the size of the ECMP set to be made by moving as few flows as possible. This is useful when the ECMP next-hops of an IP route correspond to network appliances or host servers that maintain state for the flows that they service, and moving flows requires state to be rebuilt. See Resilient ECMP hashing for details about how this feature works.

Enabling resilient ECMP hashing can be controlled using an action in a routing policy. Resilient hashing policy actions are supported only in peer import policies that apply to BGP routes received from BGP peers. This includes policies called from any of these contexts (or their subroutines):

• network-instance.protocols.bgp.import-policy

• network-instance.protocols.bgp.afi-safi.import-policy

• network-instance.protocols.bgp.group.import-policy

• network-instance.protocols.bgp.group.afi-safi.import-policy

• network-instance.protocols.bgp.neighbor.import-policy

• network-instance.protocols.bgp.neighbor.afi-safi.import-policy

There is no restriction for the AFI-SAFI family of the routes matched by the above policies. If a BGP route for a specific AFI-SAFI can create an ECMP-capable IPv4 or IPv6 route in the IP FIB table, then the resilient hashing policy actions apply to that BGP route.

For a resilient hashing policy action, you configure the following parameters:

• apply: enable or disable resilient hashing if the accepted route becomes the best BGP path; can be set to true or false.
• max-paths: set the maximum number of ECMP next-hops per route associated with the resilient-hash prefix; required if apply is set to true.
• hash-buckets-per-path: set the number of times each next-hop is repeated in the fill pattern if there are max-paths ECMP next-hops; required if apply is set to true.

Resilient hashing is enabled for an IPv4 or IPv6 prefix when either of the following are true:

• The active route for the prefix is a BGP route, and the best BGP route for the prefix was processed by an import policy that accepted the route with a resilient-hash.apply true action.

• The active route for the prefix is a non-BGP route or else a best BGP route without any import-policy resilient-hash action applied, and the route is covered by configuration of a resilient-hash-prefix in the network-instance where it is installed.

Resilient hashing is disabled for an IPv4 or IPv6 prefix when either of the following are true:

• The active route for the prefix is a BGP route, and the best BGP route for the prefix was processed by an import policy that accepted the route with a resilient-hash.apply false action.

• The active route for the prefix is a non-BGP route or else a best BGP route without any import-policy resilient-hash action applied, and the route is not covered by configuration of a resilient-hash-prefix in the network-instance where it is installed.

To program a route to support resilient ECMP, the system needs to know the maximum possible number of ECMP next-hops for the route, and the number of hash buckets to use for each possible ECMP next-hop. These values, configured with the max-paths and hash-buckets-per-path parameters, determine the hash bucket fill pattern.

The following example configures a routing policy statement with a resilient hashing action. Best BGP routes routes that match the import policy are provided with resilient-hash programming. The hash-buckets-per-path value is 4 and the max-paths value is 6, so the fill pattern has 24 hash buckets, offering space for 6 next-hops, each repeated 4 times.

--{ +* candidate shared default }--[  ]--
# info with-context routing-policy policy res-hash statement st1 action
    routing-policy {
        policy res-hash {
            statement st1 {
                action {
                    resilient-hash {
                        apply true
                        hash-buckets-per-path 4
                        max-paths 6
                    }
                }
            }
        }
    }

A regular expression is a sequence of symbols and characters expressing a pattern to be searched within the complete AS_PATH attribute. The symbols are operators that imply a matching logic with respect to terms that precede or follow them. The smallest term that can be matched is the elementary term. Elementary terms can be combined to create more complex terms, and these can be collated to create even more complex terms.

In SR Linux, the regex mode configured for an AS path set determines the elementary term and the set of operator symbols that are supported. SR Linux supports the following regex modes:

• ASN mode

  The AS path is converted to a string and the string is matched one complete AS number at a time. AS-path sets are in ASN mode by default.

• Character mode

  The AS path is converted to a string and the string is matched one character at a time.

In a routing policy, a policy statement can refer to a hybrid community set by making it the target of the leaf routing-policy.policy.statement.match.bgp.community-set. If the hybrid community-set contains multiple elements, then the matching behavior is controlled by routing-policy.community-set.match-set-options. (See Match-set-options for community-sets.)

The following table lists the valid formats for elements in a hybrid community set.

The following table lists the supported regex symbols for hybrid community-sets.

In a routing policy, a policy statement can refer to a standard community-set by making it the target of the leaf routing-policy.policy.statement.match.bgp.standard-community.standard-community-set. If the standard community-set contains multiple elements, the matching behavior is controlled by routing-policy.policy.statement.match.bgp.standard-community.match-set-options. (See Match-set-options for community-sets.)

Each standard community-set consists of a leaf-list of member elements. Each member represents either a specific community value or a regex string to be evaluated. SR Linux decides whether to treat a community-set member as an exact match or regex string as follows.

SR Linux supports the following operations for strings passed to the regex engine:

The following table shows examples of valid regex strings in standard community-sets.

In a routing policy, a policy statement can refer to an extended community-set by making it the target of the leaf routing-policy.policy.statement.match.bgp.extended-community.extended-community-set. If the extended community-set contains multiple elements, the matching behavior is controlled by routing-policy.policy.statement.match.bgp.extended-community.match-set-options. (See Match-set-options for community-sets.)

Each extended community-set consists of a leaf-list of member elements. Each member represents either a specific community value, or a regex string to be evaluated. SR Linux decides whether to treat a community-set member as an exact match or regex string as follows:

See Supported regex operations for standard and extended community-sets for valid operations for strings passed to the regex engine.

The following table shows examples of valid regex strings for route target and route origin elements in extended community-sets.

The following table shows examples of valid regex strings for link-bandwidth elements in extended community-sets.

The following table shows examples of valid regex strings for elements in generic extended community-sets.

The following table shows examples of valid regex strings for elements in Group Policy ID extended community-sets.