Routing policies

Routing policies allow detailed control of IP routes learned and advertised by routing protocols such as BGP, IS-IS, or OSPF.

Each routing policy has a sequence of rules (called entries or statements) and a default action. Each policy statement has zero or more match conditions, such as whether a route is owned by a specific protocol, and a main action, such as to accept or reject the routes; the statement may also have route-modifying actions. A route matches a statement if it meets all of the specified match conditions.

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.

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.

Routing policy match conditions

The following table summarizes the match conditions supported in SR Linux routing policies.

Table 1. Match conditions for routing policies
Match condition Description
protocol

Test if the route is owned by a specific protocol. The following options are supported:

  • aggregate
  • arp-nd
  • bgp
  • bgp-evpn
  • bgp-ipvpn
  • bgp-label
  • dhcp
  • host
  • isis
  • local
  • ospfv2
  • ospfv3
  • static
family

Test if the prefix is associated with any of the AFI/SAFI (address families) listed. The following options are supported:

  • ipv4-unicast
  • ipv6-unicast
  • l3vpn-ipv4-unicast
  • l3vpn-ipv6-unicast
  • ipv4-labeled-unicast
  • ipv6-labeled-unicast
  • evpn
  • route-target
prefix-set

Test if the route matches any entry in a configured prefix-set. See Prefix sets.
internal-tags.tag-set

Test if the route contains members of a configured tag-set. See "Configuring route internal tags" in the SR Linux EVPN Guide.
bgp.community-set

Test if a BGP community attached to the route matches the list of member elements and match-set-option in the BGP community-set. See BGP community-sets.
bgp.as-path-length Test if the AS-path length of the route is a specific value or in a range.
bgp.as-path-set

Test if the route has an AS path that matches the regular expression in the configured AS-path set. See AS path sets.
bgp.evpn.route-type Test if the EVPN route type is a specific type (1-5).
isis.level Test if the IS-IS route is associated with L1 or L2.
isis.route-type

Test if the IS-IS route is internal or external (redistributed from another protocol).

An IPv4 prefix is external if it is signaled in TLV 130 or TLV135 with RFC 7794 X flag=1.

An IPv6 prefix is external if TLV 236/TLV 237 external bit = 1.
ospf.area-id Test if the OSPFv2 or OSPFv3 route is associated with the specified area ID.
ospf.route-type Test if the OSPFv2 or OSPFV3 route is a specific route type: any of intra-area, inter-area, type-1-ext, type-2-ext, type-1-nssa, type-2-nssa, summary-aggregate, or nssa-aggregate.
ospf.instance-id Test if the OSPFv2 or OSPFv3 route is associated with the specified instance ID.

Specifying match conditions in a routing policy

You can specify the match conditions listed in Match conditions for routing policies in a policy statement. If a statement has no match conditions defined, all routes evaluated by the policy are considered to be matches.

Test if the route is owned by BGP

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

Test if the route prefix is associated with an address family

The following example matches routes with a prefix belonging to the IPv4 or IPv6 labeled unicast address family:

--{ candidate shared default }--[  ]--
# info routing-policy policy policy02
    routing-policy {
        policy policy02 {
            statement 100 {
                match {
                    family [
                        ipv4-labeled-unicast
                        ipv6-labeled-unicast
                    ]
                }
            }
        }
    }

Test if an OSPF route is a specific route type

The following example matches OSPF type 2 external routes:

--{ candidate shared default }--[  ]--
# info routing-policy policy policy03
    routing-policy {
        policy policy03 {
            statement 100 {
                match {
                    protocol ospfv2
                    ospf {
                        route-type type-2-ext
                    }
                }
            }
        }
    }

Routing policy actions

If a route matches a policy statement, the actions configured in the policy are applied to the route, including route property modifications. Depending on the configured action, the route may continue to be analyzed by further routing policy statements (if any), or the final disposition (either accept or reject) of the route is determined.

Default routing policy action

Each routing policy can optionally be configured with a default action, which is applied to routes that do not match any policy statement. The default action specifies a main action and optionally one or more route property modification actions. The default action is applied to all routes evaluated by the policy that do not match any statement, or are only matched by statements that are non-terminating, such as next-statement.

If the default action is explicitly configured as accept or reject, evaluation ends at the current policy even if there are further policies in the chain. If a policy does not have a configured default action, or the default action for the policy is next-policy or next-statement, then routes that do not match any statement in the policy are automatically evaluated by the next policy in the chained list. See Specifying a default action for a configuration example.

Main routing policy actions

The following table lists the main routing policy actions. These actions can be configured for the policy-result for the default action or at the statement action level in a routing policy.
Table 2. Main routing policy actions
Action Description
accept The route is accepted, route property modifications are applied, and evaluation stops immediately; further statements and policies are not considered.
reject The route is dropped and evaluation stops immediately; further statements and policies are not considered.
next-statement No immediate decision is made about whether to accept or reject the route. Route policy modifications are applied, and evaluation continues automatically to the next statement. If there are no further statements in this policy, the default action of the current policy applies.
next-policy No immediate decision is made about whether to accept or reject the route. Route policy modifications are applied, and evaluation skips the remainder of the statements in the current policy continuing automatically to the first statement in the next policy in the chained list. If there are no further policies, then the default action of the last policy in the chain applies.

If no value is configured for policy-result then the implicit default is next-statement (if not configured at the statement action level) or next-policy (if not configured at the default-action level).

Route property modification actions

The following table lists the route property modification actions that can be specified in a routing policy.

Table 3. Route property modification actions
Action Description
bgp.as-path.prepend Prepend a specific AS number one or more times to the AS path.
bgp.as-path.remove Clear the AS path to make it empty.
bgp.as-path.replace Clear the existing AS path and replace it a new AS_SEQUENCE containing the listed AS numbers.
bgp.communities.add Add all of the non-regex community members in the referenced community-set.
bgp.communities.remove Remove all of the communities that match any regex or non-regex member in the referenced community-set.
bgp.communities.replace Delete all of the existing communities and then add all of the non-regex community members in the referenced community-set.
bgp.local-preference.set Set or modify the LOCAL_PREF to the specified value in matching BGP routes.
bgp.med.set

Set or modify the MED to the specified value in matching BGP routes. See Policy actions for setting MED in BGP routes.
bgp.next-hop-resolution.set-tag-set Reference a tag-set to be used for controlling next-hop resolution.
bgp.next-hop.set Set or modify the BGP next-hop address to a specified IPv4 or IPv6 address or to the keyword self.
bgp.origin.set Set or modify the BGP ORIGIN attribute value to the specified value.
internal-tags.tag-set Add the tags in the tag-set as internal tags.
route-preference.set Overwrite the route preference with the specified value.

Specifying actions in a routing policy

You can specify the actions listed in Routing policy actions to routes that match a policy statement.

Accept static routes

The following example configures a routing policy statement to accept static routes:

--{ +* candidate shared default }--[  ]--
# info routing-policy policy policy01
    routing-policy {
        policy policy01 {
            statement st1 {
                match {
                    protocol static
                }
                action {
                    policy-result accept
                }
            }
        }
    }

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 proceed to the next statement. If the route matches the second statement, the action is to specify a new value for the origin attribute of the BGP route.

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

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

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.

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.

Apply a routing policy to imported routes

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

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

Apply a routing policy to BGP routes exported from a peer-group

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

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

Apply a routing policy to BGP routes exported from a BGP neighbor

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

--{ * candidate shared default }--[  ]--
# info  network-instance default protocols bgp neighbor 192.168.11.1
    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 that matches BGP routes. The action for the policy is next-policy, so routes that match the first policy are evaluated by the second policy, whose action is to replace the AS path in matching routes. 

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

AS path sets

In a routing policy, an AS path set groups one or more AS paths using a regular expression. An AS path regular expression is a string consisting of AS numbers and (usually) one or more regular expression operators.

When a route is compared to an AS path regular expression, each 4-byte AS number is extracted, one-by-one from the AS path, starting with the most recent AS and proceeding to the oldest or originating AS, and checked for a match against the regular expression. If there is any AS number that does not match the pattern, then the route is considered not a match for the AS path regular expression, and therefore not a match for the policy statement where this match condition is used.

The following table lists supported operators for an AS path regular expression.

Table 4. Operators for AS path regular expressions
Operator Description
| Matches the term on alternate sides of the pipe.
* Matches multiple occurrences of the term.
? Matches 0 or 1 occurrence of the term.
+ Matches 1 or more occurrence of the term.
( ) Used to parenthesize so a regular expression is considered as one term.
[ ] Used to demarcate a set of elementary or range terms.
[^ ] Used to demarcate a set of elementary or range terms that are explicitly not-matching.
- Used between the start and end of a range.
{m,n} Matches least m and at most n repetitions of the term.
{m} Matches exactly m repetitions of the term.
{m,} Matches m or more repetitions of the term.
^ Matches the beginning of the string.
$ Matches the end of the string.
\ An escape character to indicate that the following character is a match criteria and not a grouping delimiter.
<> Matches any AS path numbers containing a confederation SET or SEQ.

Configuring an AS path set

To use an AS path set in a routing policy, you configure a regular expression for the AS path set, then specify the AS path set as a match condition in the routing policy.

The following example configures an AS path set that consists of a regular expression "^100 .*" and the AS path set is specified as a match condition in a routing policy. The policy matches routes whose AS path matches the regular expression. An AS path set can have a maximum of one regular expression configured. See Operators for AS path regular expressions for a list of valid operators.

In this example, a route with AS path [100 200] matches the regular expression in the AS path set, and the action specified in the policy is applied to the route.

--{ candidate shared default }--[  ]--
# info routing-policy
    routing-policy {
        as-path-set a1 {
            expression "^100 .*"
        }
        policy p1 {
            statement s1 {
                match {
                    bgp {
                        as-path-set a1
                    }
                }
                action {
                    bgp {
                        as-path {
                            replace [
                                300
                                400
                            ]
                        }
                    }
                }
            }
        }
    }

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

Prefix sets

In a routing policy, a prefix set groups one or more IPv4 and, or IPv6 prefix matching entries. A prefix matching entry has two components:

  • an IPv4 or IPv6 prefix, specifying an IPv4 or IPv6 address with zeroed host bits and a prefix length; for example, 192.168.1.0/21
  • a mask-length-range, specifying either exact or a range in the format <a>..<b>, where <a> is the starting prefix length (0-32 for IPv4, 0-128 for IPv6), and <b> is the ending prefix length (0-32 for IPv4, 0-128 for IPv6)

Configuring a prefix set

To configure a prefix set for a routing policy, you specify the member elements, then specify the prefix set as a match condition in the routing policy.

The following example configures a prefix set that consists of two member elements. The prefix set is specified as a match condition in a routing policy.

--{ candidate shared default }--[  ]--
# info routing-policy
    routing-policy {
        prefix-set pset1 {
            prefix 192.168.10.0/21 mask-length-range 21..24 {
            }
            prefix 192.168.1.0/24 mask-length-range exact {
            }
        }
        policy p1 {
            statement s1 {
                match {
                    prefix-set pset1
                }
                action {
                    policy-result accept
                }
            }
        }
    }

Resequencing statements in a routing policy

Each routing policy statement has a 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.

The definition of the sequence of statements is fully flexible and can be defined as required using the insert command. If the insert command is not used, new statements are added to the end of the policy.

In the following examples, routing policy policy01 consists of three statements: red, green, and blue.

--{ +* candidate shared default }--[  ]--
# info routing-policy policy policy01
    routing-policy {
        policy policy01 {
            statement red {
                match {
                    protocol bgp
                }
                action {
                    policy-result accept
                }
            }
            statement green {
                match {
                    prefix-set pset1
                }
                action {
                    policy-result reject
                }
            }
            statement blue {
                match {
                    family [
                        ipv4-unicast
                        ipv6-unicast
                    ]
                }
                action {
                    policy-result next-policy
                }
            }
        }
    }

Move a statement to the end of a routing policy

The following example moves statement red to the end of the routing policy:

--{ +* candidate shared default }--[  ]--
# routing-policy policy policy01
--{ +* candidate shared default }--[ routing-policy policy policy01 ]--
# insert statement red last
--{ +* candidate shared default }--[ routing-policy policy policy01 ]--
# info
    statement green {
        match {
            prefix-set pset1
        }
        action {
            policy-result reject
        }
    }
    statement blue {
        match {
            family [
                ipv4-unicast
                ipv6-unicast
            ]
        }
        action {
            policy-result next-policy
        }
    }
    statement red {
        match {
            protocol bgp
        }
        action {
            policy-result accept
        }
    }

Move a statement to the beginning of a routing policy

The following example moves statement blue to the beginning of the routing policy:

--{ +* candidate shared default }--[  ]--
# routing-policy policy policy01
--{ +* candidate shared default }--[ routing-policy policy policy01 ]--
# insert statement blue first
--{ +* candidate shared default }--[ routing-policy policy policy01 ]--
# info
    statement blue {
        match {
            family [
                ipv4-unicast
                ipv6-unicast
            ]
        }
        action {
            policy-result next-policy
        }
    }
    statement red {
        match {
            protocol bgp
        }
        action {
            policy-result accept
        }
    }
    statement green {
        match {
            prefix-set pset1
        }
        action {
            policy-result reject
        }
    }

Move a statement before an existing statement

The following example moves statement blue before statement green:

--{ +* candidate shared default }--[  ]--
# routing-policy policy policy01
--{ +* candidate shared default }--[ routing-policy policy policy01 ]--
# insert statement blue before green
--{ +* candidate shared default }--[ routing-policy policy policy01 ]--
# info
    statement red {
        match {
            protocol bgp
        }
        action {
            policy-result accept
        }
    }
    statement blue {
        match {
            family [
                ipv4-unicast
                ipv6-unicast
            ]
        }
        action {
            policy-result next-policy
        }
    }
    statement green {
        match {
            prefix-set pset1
        }
        action {
            policy-result reject
        }
    }

Move a statement after an existing statement

The following example moves statement red after statement green:

--{ +* candidate shared default }--[  ]--
# routing-policy policy policy01
--{ +* candidate shared default }--[ routing-policy policy policy01 ]--
# insert statement red after green
--{ +* candidate shared default }--[ routing-policy policy policy01 ]--
# info
    statement green {
        match {
            prefix-set pset1
        }
        action {
            policy-result reject
        }
    }
    statement red {
        match {
            protocol bgp
        }
        action {
            policy-result accept
        }
    }
    statement blue {
        match {
            family [
                ipv4-unicast
                ipv6-unicast
            ]
        }
        action {
            policy-result next-policy
        }
    }