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 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.

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.