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 numerical sequence identifier that determines its order relative to other statements in that policy. When a route is analyzed by a policy, it is evaluated by each statement in sequential order.
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 sequence number. If a policy has multiple statements, they are processed in sequence-number order. 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 routes by their standard and large communities.
-
Match BGP routes by their AS path length.
-
Match BGP routes by their AS path encoding.
-
Match BGP routes by whether the EVPN route has an Ethernet Segment identifier (ESI) that matches a member of a specified ESI set.
-
Match BGP routes by whether the EVPN route has an Ethernet tag ID that matches a member of a specified Ethernet tag set.
-
Match BGP routes by whether the EVPN type-2 route has a MAC address that matches a member of a specified MAC set.
-
Match BGP routes by whether the originating router’s IP address in an EVPN type-3 or type-4 route matches a specified IP address.
-
Match BGP routes by whether the EVPN route is a specified route type (ethernet-ad, mac-ip, ethernet-segment, imet, or ip-prefix).
-
Match BGP routes by whether the BGP VPN route has a specified route distinguisher value.
-
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 IS-IS routes by their tag value.
-
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 routes based on EVPN route type.
-
Match routes based on IP addresses and prefixes via prefix-sets for route types 2 and 5.
-
Match routes based BGP encapsulation extended community.
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.
-
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.
-
Proceed to the next statement in the policy
-
Proceed to the next policy
The following example specifies a policy with two statements. If a route matches the first statement, the action is to proceed to the next statement. If the route matches the second statement, the action is to accept.
--{ candidate shared default }--[ ]--
# info routing-policy
routing-policy {
policy policy02 {
statement 100 {
match {
protocol bgp
}
action {
next-entry
}
}
statement 101 {
match {
prefix-set western
}
action {
accept
}
}
}
}
Specifying a default action
You can optionally specify the policy action for routes that do not match the conditions defined in the policy. 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 entries 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 {
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 {
}
}
}
}
}
}
}