Routing policies

The SR Linux supports policy-based routing. Policy-based routing controls the size and content of the routing tables, the routes that are advertised, and the best route to take to reach a destination.

Each routing policy has a sequence of rules (called entries or statements) and a default action. Each statement has a numerical sequence identifier that determines its order relative to other statements in that policy. The statement supports both alphanumerical and numerical sequence identifiers. When a route is analyzed by a policy, it is evaluated by each statement in sequential order. The definition of the sequence of statements is fully flexible and can be defined as required using the keywords first/last/before/after in the insert command. If the insert command is not used, the statement is added to the end of the policy.

Each policy statement has zero or more match conditions and a base action (either accept or reject); the statement may also have route-modifying actions. A route matches a statement if it meets all of the specified match conditions.

The first statement that matches the route determines the actions that are applied to the route. If the route is not matched by any statements, the default action of the policy is applied. If there is no default action, then a protocol- and context-specific default action is applied.

All routes match a statement with no match conditions. When a route fulfills the match conditions of a statement, the base action of the statement is applied, along with all of its route-modifying actions.

Creating a routing policy

A routing policy consists of one or more statements that contain the following:

Match conditions, such as protocol type, AS path length, and address family, against which routes are evaluated
Actions, such as accept or reject, for routes that match the conditions in the statement

Each statement has a specified position in the policy. If a policy has multiple statements, they are processed in the order they are put in the policy. In addition, you can specify a default action that applies to routes that do not match any statement in the policy.

Specifying match conditions

You can specify the following match conditions in a policy statement:

Match routes by their protocol type – BGP, static, direct, host, IS-IS, OSPF, and so on.
Match routes of any protocol by their address family – IPv4-unicast, IPv6-unicast, EVPN.
Match routes of any protocol by their IPv4/IPv6 prefix.
Match aggregate and BGP IPv4/IPv6 routes by their standard and large communities.
Match BGP routes by their AS path length.
Match BGP routes by their AS path encoding (using a regular expression).
Match BGP routes by whether the EVPN route is a specified route type (ethernet-ad, mac-ip, ethernet-segment, imet, or ip-prefix).
Match IS-IS routes by their association with either Level1 (L1) or Level2 (L2).
Match IS-IS routes by their route type (internal or external). An IPv4 route is internal if the prefix was signaled in TLV 128. An IPv4 route is external if the prefix was signaled in TLV 130. The encoding of TLV 236 indicates whether an IPv6 route is internal or external.
Match OSPF routes by their area ID.
Match OSPF routes by their route type (intra-area, inter-area, type-1-ext, type-2-ext, type-1-nssa, type-2-nssa, summary-aggregate, or nssa-aggregate).
Match OSPF routes by instance ID.
Match EVPN IP prefix routes based on protocol bgp-evpn.
Match routes based on IP addresses and prefixes via prefix-sets for route types 2 and 5.

If a statement has no match conditions defined, all routes evaluated by the policy are considered to be matches.

The following example specifies BGP protocol as a match condition in a policy statement:

--{ candidate shared default }--[  ]--
# info routing-policy policy policy01
    routing-policy {
        policy policy01 {
            statement 100 {
                match {
                    protocol bgp
                }
            }
        }
    }

Specifying a list as a match condition

You can specify a list of items, such as address prefixes, autonomous systems, BGP communities, and Ethernet tags as match criteria. To do this, you configure the list and include the list in a policy statement.

The following example specifies a list of prefixes that can be used as a match condition in a policy statement:

--{ candidate shared default }--[  ]--
# info routing-policy
    routing-policy {
        prefix-set western {
            prefix 10.10.0.1/32 mask-length-range exact {
            }
            prefix 10.10.0.2/32 mask-length-range exact {
            }
            prefix 10.10.0.3/32 mask-length-range exact {
            }
            prefix 10.10.0.4/32 mask-length-range exact {
            }
        }
    }

Specifying actions

The following are valid actions for routes that meet the match conditions in a statement:

Accept the route.
Reject the route.
Modify the AS path of a BGP route by prepending additional AS numbers.
Modify the AS path of a BGP route by deleting the current AS path and replacing it with a new AS path (a sequence of zero or more AS numbers).
Add, delete, or replace standard and large communities attached to a BGP route.
Modify the LOCAL_PREF attribute of a BGP route by specifying a new value.
Modify the ORIGIN attribute of a BGP route by specifying a new value.
Replace the MED attribute of a BGP route with a new value, either the route-table metric of the route that resolves the BGP next-hop, or a specified MED value.
Set the next-hop-self option for a BGP route.
Set the next-hop-unchanged option for a BGP route.
Add, delete, or replace the route tag associated with an IS-IS route.

Set ORIGIN attribute for matching BGP routes

The following example specifies a policy with two statements. If a BGP route matches the first statement, the action is to specify a new value for the ORIGIN attribute of the BGP route. If the route matches the second statement, the action is to accept the route.

--{ candidate shared default }--[  ]--
# info routing-policy
    routing-policy {
        policy policy02 {
            statement myEntry100 {
                match {
                    protocol bgp
                }
                action {
                    bgp {
                        origin {
                            set egp
                        }
                    }
                }
            }
            statement 101 {
                match {
                    prefix-set western
                }
                action {
                    policy-result accept
                }
            }
        }
    }

Policy actions for setting MED in BGP routes

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.

Specifying a default action

You can optionally specify the policy action for routes that do not match the conditions defined in the policy statements. The default action can be set to all available action states including accept, reject, next-entry, and next-policy.

If a default action is defined, and no matches occur with the statements in the policy, the default action is used.
If no default action is specified, the default behavior of the protocol controls whether the routes match.

For BGP, the default import action is to accept all routes from BGP. For internal routes, the default export action is to advertise them to BGP peers. For external routes, the default export action is not to advertise them to BGP peers.

The following example defines a policy where the default action for non-matching routes is to reject them:

--{ candidate shared default }--[  ]--
# info routing-policy
    routing-policy {
        policy policy01 {
            default-action {
                policy-result reject
            }
        }
    }

Applying a routing policy

Routing policies can be applied to routes received from other routers (imported routes), as well as routes advertised to other routers (exported routes). Routing policies can be applied at the network-instance level, peer-group level, and neighbor level.

The following example specifies that BGP in the default network-instance applies policy01 to imported routes:

--{ candidate shared default }--[  ]--
# info network-instance default
    network-instance default {
        protocols {
            bgp {
                import-policy policy01
                }
            }

The following example applies policy02 to BGP routes exported from the peers in peer-group headquarters1:

--{ candidate shared default }--[  ]--
# info network-instance default
    network-instance default {
        protocols {
            bgp {
                group headquarters1 {
                    export-policy policy02
                    }
                }
            }
        }

The following example applies policy02 to BGP routes exported from a specific BGP neighbor:

--{ * candidate shared default }--[  ]--
# info network-instance default
    network-instance default {
        protocols {
            bgp {
                neighbor 192.168.11.1 {
                    export-policy policy02
                }
            }
        }
    }

Applying a default policy to eBGP sessions

You can specify the action to take for routes exported to or imported from eBGP peers to which no configured policy applies. This is set with the ebgp-default-policy command and the export-reject-all and import-reject-all parameters.

The export-reject-all parameter, when set to true, causes all outbound routes that do not match a configured export policy to be rejected as if they had been rejected by a configured export policy. The default is true.
The import-reject-all parameter, when set to true, causes all inbound routes that do not match a configured import policy to be rejected as if they had been rejected by a configured import policy. The default is true.

The following example allows a BGP neighbor to export a default route even though the route is not subject to any configured policy:

--{ * candidate shared default }--[  ]--
# info network-instance default
    network-instance default {
        protocols {
            bgp {
                ebgp-default-policy {
                    export-reject-all false
                }
                neighbor 2001:db8::c11 {
                    send-default-route {
                        ipv6-unicast true
                    }
                }
            }
        }
    }

Replacing an AS path

You can configure a routing policy where the AS path in matching routes is replaced by a list of AS numbers specified in the policy. For routes that match the policy, the current AS path is deleted and replaced with an AS_SEQ element containing the AS numbers listed in the policy in their configured sequence.

If you configure an empty AS list in the policy, then the current AS path in a matching route is deleted, and it would then have a null AS_PATH attribute.

The following is an example of a routing policy whose action is to replace the AS path in matching routes.

--{ candidate shared default }--[  ]--
# info routing-policy
    routing-policy {
        policy policy02 {
            statement 100 {
                match {
                    protocol bgp
                }
                action {
                    bgp {
                        as-path {
                            replace [
                                12
                                13
                                14
                            ]
                        }
                    }
                }
            }
        }
    }

BGP community-sets

You can configure a BGP community-set that can be used as a match condition in a routing policy. A BGP community-set contains a list of member elements and a match-set-option that indicates what constitutes a matching route.

An element in a BGP community-set can be a standard BGP community value, regular expression, or well-known name, or else a large BGP community value or regular expression (see Supported community-set member formats). The match-set-option can be one of the following:

all: a route matches the community-set if every element in the community-set is matched by a community attached to the route. If you do not specify a match-set-option, this is the default.
any: a route matches the community-set if there is at least one element in the community-set that is matched by a community attached to the route.
invert: a route matches the community-set if none of the elements in the community-set are matched by a community attached to the route.

Table 1. Supported community-set member formats
String format	Definition
<0-65535>:<0-65535>	Standard community matched exactly
<0-4294967295>:<0-4294967295>:<0-4294967295>	Large community matched exactly
<regex1>:<regex2>	Standard community matched by two regular expressions
<regex1>:<regex2>:<regex3>	Large community matched by three regular expressions
bgp-tunnel-encap:(MPLS\|VXLAN)	BGP tunnel encapsulation extended community
color:NN:<0-4294967295>	Color extended community matched exactly
no-advertise	Well-defined standard community 'NO-ADVERTISE'
no-export	Well-defined standard community 'NO-EXPORT'
no-export-subconfed	Well-defined standard community 'NO-EXPORT-SUBCONFED'
no-peer	Well-defined standard community 'NO-PEER'
origin:<0-65535>:<0-4294967295>	Type0 route-origin extended community matched exactly
origin:<0-4294967295>:<0-65535>	Type2 route-origin extended community matched exactly
origin:<ipv4-address>:<0-65535>	Type1 route-origin extended community matched exactly
origin:<regex1>:<regex2>	Route-origin extended community matched by two regular expressions
target:<0-65535>:<0-4294967295>	type0 route-target extended community matched exactly
target:<0-4294967295>:<0-65535>	Type2 route-target extended community matched exactly
target:<ipv4-address>:<0-65535>	Type1 route-target extended community matched exactly
target:<regex1>:<regex2>	Route-target extended community matched by two regular expressions

Configuring a BGP community-set

To configure a BGP community-set for a routing policy, you specify the member elements and match-set-option, then specify the community set as a match condition in the routing policy.

The following example configures a BGP community-set that consists of two member elements. The match-set-option is invert, so a route matches this community-set if neither of the elements in the community-set are matched by a community attached to the route. The community-set is specified as a match condition in a routing policy.

--{ candidate shared default }--[  ]--
# info routing-policy
    routing-policy {
        community-set cs1 {
            match-set-options invert
            member [
                no-advertise
                no-export
            ]
        }
        policy p1 {
            statement 1 {
                match {
                    bgp {
                        community-set cs1
                    }
                }
            }
        }
    }