Understanding Routing Policies

Overview of Routing Policies

Routing policies are implemented in the following steps:

Define rules: The rules that contain characteristics of routes to which routing policies are applied need to be defined. Specifically, you need to define a set of matching rules regarding different attributes of routing information, such as the destination address and the source IP address of the device that advertises routes. A filter, the core of a routing policy, is used to define a set of matching rules.
Apply rules: The rules are used in a routing policy to advertise, accept, and import routes.

Filter

By using filters, you can define matching rules for a group of routing policies. The NetEngine 8000 F provides multiple types of filters for routing policies. Table 1 lists the filters supported by the device and their application scopes and matching conditions.

**Table 1** Filters supported by the device
Filter	Application Scope	Matching Rules
Access control list (ACL)	Dynamic routing protocols	Inbound interface, source or destination IP address, protocol type, and source or destination port number
IP prefix list	Dynamic routing protocols	Source and destination IP addresses and next hop address
AS_Path	BGP	AS_Path attribute
Community	BGP	Community attribute
Large-community	BGP	Large-community attribute
Extended community	VPN	Extended community attribute
Route distinguisher (RD)	VPN	RD attribute
Route-Policy	Dynamic routing protocols	Destination IP address, next hop address, cost, interface information, route type, ACL, IP prefix list, AS_Path filter, community filter, extended community filter, Layer 2 VNI list, Layer 3 VNI list, MAC address list, Ethernet Tag list, and RD.

The ACL, IP prefix list, AS_Path filter, large-community filter, community filter, extended community filter, and RD filter can only be used to filter routes and cannot be used to modify the attributes of matched routes. A route-policy is a comprehensive filter, and it can use the matching rules of the ACL, IP prefix list, AS_Path filter, community filter, extended community filter, and RD filter to filter routes. In addition, attributes of the matched routes can be modified. The following sections describe the filters in more detail.

ACL

An ACL is a set of sequential filtering rules. Users can define rules based on packet information, such as inbound interfaces, source or destination IP addresses, protocol types, or source or destination port numbers and specify an action to deny or permit packets. After an ACL is configured, the system classifies received packets based on the rules defined in the ACL and denies or permits the packets accordingly.

An ACL only classifies packets based on defined rules and filters packets only after it is applied to a routing policy.

ACLs can be configured for both IPv4 routes and IPv6 routes. Based on the usage, ACLs are classified as interface-based ACLs, basic ACLs, or advanced ACLs. Users can specify the IP address and subnet address range in an ACL to match the source IP address, destination network segment address, or the next hop address of a route.

ACLs can be configured on network devices, such as access and core devices, to improve network security and stability. For example:

Protect the devices against IP, TCP, and Internet Control Message Protocol (ICMP) packet attacks.
Control network access. For example, ACLs can be used to control the access of enterprise network users to external networks, the specific network resources that users can access, and the period for which users can access networks.
Limit network traffic and improve network performance. For example, ACLs can be used to limit bandwidth for upstream and downstream traffic, charge for the bandwidth that users have applied for, and fully use high-bandwidth network resources.

For details about ACL features, see ACL Description.

IP Prefix List

An IP prefix list contains a group of route filtering rules. Users can specify the prefix and mask length range to match the destination network segment address or the next hop address of a route. An IP prefix list is used to filter routes that are advertised and received by various dynamic routing protocols.

An IP prefix list is easier and more flexible than an ACL. However, if a large number of routes with different prefixes need to be filtered, configuring an IP prefix list to filter the routes is complex.

IP prefix lists can be configured for both IPv4 routes and IPv6 routes, and they share the same implementation process. An IP prefix list filters routes based on the mask length or mask length range.

Mask length: An IP prefix list filters routes based on IP address prefixes. An IP address prefix is defined by an IP address and the mask length. For example, for route 10.1.1.1/16, the mask length is 16 bits, and the valid prefix is 16 bits (10.1.0.0).
Mask length range: Routes with the IP address prefix and mask length within the range defined in the IP prefix list meet the matching rules.

0.0.0.0 is a wildcard address. If the IP prefix is 0.0.0.0, specify either a mask or a mask length range, with the following results:

If a mask is specified, all routes with the mask are permitted or denied.
If a mask length range is specified, all routes with the mask length in the range are permitted or denied.

The following table describes the implementation of route matching rules when the preceding wildcard address is used.

**Table 2** Implementation of wildcard address-based route matching rules (IPv4)
Whether greater-equal and less-equal Exist in the Post-Processing Configuration	Condition	Matching Result	Example
Neither greater-equal nor less-equal exists.	The post-processing ipv4-address and mask-length are 0.0.0.0 and 0, respectively.	Matches only the default IPv4 route.	An IP prefix list cannot be configured if the prefix and mask do not match. For example: ip ip-prefix aa index 10 permit 1.1.1.1 0 Error: Failed to add the address prefix list 0.0.0.0/0, because the destination address and mask do not match. Correct configuration: ip ip-prefix aa index 10 permit 0.0.0.0 0 Matching result: Only the default route is permitted.
Neither greater-equal nor less-equal exists.	The post-processing ipv4-address and mask-length are 0.0.0.0 and X (non-0 value), respectively.	Matches all routes with the mask length of X.	Pre-processing: ip ip-prefix aa index 10 permit 0.0.1.1 16 Post-processing: ip ip-prefix aa index 10 permit 0.0.0.0 16 Matching result: The routes with the mask length of 16 are permitted.
greater-equal exists, but less-equal does not.	The post-processing ipv4-address and mask-length are 0.0.0.0 and 0, respectively.	Matches all the routes whose mask length is within the range from greater-equal to 32.	An IP prefix list cannot be configured if the prefix and mask do not match. For example: ip ip-prefix aa index 10 permit 1.1.1.1 0 greater-equal 16 Error: Failed to add the address prefix list 0.0.0.0/0, because the destination address and mask do not match. Correct configuration: ip ip-prefix aa index 10 permit 0.0.0.0 0 greater-equal 16 less-equal 32 Matching result: The routes whose mask length is within the range from 16 to 32 are permitted.
greater-equal exists, but less-equal does not.	The post-processing ipv4-address and mask-length are 0.0.0.0 and X (non-0 value), respectively.	Matches all the routes whose mask length is within the range from greater-equal to 32.	Pre-processing: ip ip-prefix aa index 10 permit 0.0.1.1 16 greater-equal 20 Post-processing: ip ip-prefix aa index 10 permit 0.0.0.0 16 greater-equal 20 less-equal 32 Matching result: The routes whose mask length is within the range from 20 to 32 are permitted.
greater-equal does not exist, but less-equal does.	The post-processing ipv4-address and mask-length are 0.0.0.0 and 0, respectively.	Matches all the routes whose mask length is within the range from 0 to less-equal.	An IP prefix list cannot be configured if the prefix and mask do not match. For example: ip ip-prefix aa index 10 permit 1.1.1.1 0 less-equal 30 Error: Failed to add the address prefix list 0.0.0.0/0, because the destination address and mask do not match. Correct configuration: ip ip-prefix aa index 10 permit 0.0.0.0 0 less-equal 30 Matching result: The routes whose mask length is within the range from 0 to 30 are permitted.
greater-equal does not exist, but less-equal does.	The post-processing ipv4-address and mask-length are 0.0.0.0 and X (non-0 value), respectively.	Matches all the routes whose mask length is within the range from X to less-equal.	Pre-processing: ip ip-prefix aa index 10 permit 0.0.1.1 16 less-equal 30 Post-processing: ip ip-prefix aa index 10 permit 0.0.0.0 16 greater-equal 16 less-equal 30 Matching result: The routes whose mask length is within the range from 16 to 30 are permitted.
Both greater-equal and less-equal exist.	The post-processing ipv4-address and mask-length are 0.0.0.0 and 0, respectively.	Matches all the routes whose mask length is within the range from greater-equal to less-equal.	An IP prefix list cannot be configured if the prefix and mask do not match. For example: ip ip-prefix aa index 10 permit 1.1.1.1 0 greater-equal 5 less-equal 30 Error: Failed to add the address prefix list 0.0.0.0/0, because the destination address and mask do not match. Correct configuration: ip ip-prefix aa index 10 permit 0.0.0.0 0 greater-equal 5 less-equal 30 Matching result: The routes whose mask length is within the range from 5 to 30 are permitted.
Both greater-equal and less-equal exist.	The post-processing ipv4-address and mask-length are 0.0.0.0 and X (non-0 value), respectively.	Matches all the routes whose mask length is within the range from greater-equal to less-equal.	Pre-processing: ip ip-prefix aa index 10 permit 0.0.1.1 16 greater-equal 20 less-equal 30 Post-processing: ip ip-prefix aa index 10 permit 0.0.0.0 16 greater-equal 20 less-equal 30 Matching result: The routes whose mask length is within the range from 20 to 30 are permitted.

**Table 3** Implementation of wildcard address-based route matching rules (IPv6)
Whether greater-equal and less-equal Exist in the Post-Processing Configuration	Condition	Matching Result	Example
Neither greater-equal nor less-equal exists.	The post-processing ipv6-address and prefix-length are :: and 0, respectively.	Matches only the default IPv6 route.	An IP prefix list cannot be configured if the prefix and mask do not match. For example: ip ipv6-prefix aa index 10 permit 1::1 0 Error: Failed to add the address prefix list ::/0, because the destination address and mask do not match. Correct configuration: ip ipv6-prefix aa index 10 permit :: 0 Matching result: Only the default IPv6 route is permitted.
Neither greater-equal nor less-equal exists.	The post-processing ipv6-address and prefix-length are :: and X (non-0 value), respectively.	Matches all IPv6 routes with the prefix length of X.	Pre-processing: ip ipv6-prefix aa index 10 permit ::1:1 96 Post-processing: ip ipv6-prefix aa index 10 permit :: 96 Matching result: The IPv6 routes with the prefix length of 96 are permitted.
greater-equal exists, but less-equal does not.	The post-processing ipv6-address and prefix-length are :: and 0, respectively.	Matches all the IPv6 routes whose prefix length is within the range from greater-equal to 128.	An IP prefix list cannot be configured if the prefix and mask do not match. For example: ip ipv6-prefix aa index 10 permit 1::1 0 greater-equal 16 Error: Failed to add the address prefix list ::/0, because the destination address and mask do not match. Correct configuration: ip ipv6-prefix aa index 10 permit :: 0 greater-equal 16 less-equal 128 Matching result: The IPv6 routes whose prefix length is within the range from 16 to 128 are permitted.
greater-equal exists, but less-equal does not.	The post-processing ipv6-address and prefix-length are :: and X (non-0 value), respectively.	Matches all the IPv6 routes whose prefix length is within the range from greater-equal to 128.	Pre-processing: ip ipv6-prefix aa index 10 permit ::1:1 96 greater-equal 120 Post-processing: ip ipv6-prefix aa index 10 permit :: 96 greater-equal 120 less-equal 128 Matching result: The IPv6 routes whose prefix length is within the range from 120 to 128 are permitted.
greater-equal does not exist, but less-equal does.	The post-processing ipv6-address and prefix-length are :: and 0, respectively.	Matches all the IPv6 routes whose prefix length is within the range from 0 to less-equal.	An IP prefix list cannot be configured if the prefix and mask do not match. For example: ip ipv6-prefix aa index 10 permit 1::1 0 less-equal 120 Error: Failed to add the address prefix list ::/0, because the destination address and mask do not match. Correct configuration: ip ipv6-prefix aa index 10 permit :: 0 less-equal 120 Matching result: The IPv6 routes whose prefix length is within the range from 0 to 120 are permitted.
greater-equal does not exist, but less-equal does.	The post-processing ipv6-address and prefix-length are :: and X (non-0 value), respectively.	Matches all the IPv6 routes whose prefix length is within the range from X to less-equal.	Pre-processing: ip ipv6-prefix aa index 10 permit ::1:1 96 less-equal 120 Post-processing: ip ipv6-prefix aa index 10 permit :: 96 greater-equal 96 less-equal 120 Matching result: The IPv6 routes whose prefix length is within the range from 96 to 120 are permitted.
Both greater-equal and less-equal exist.	The post-processing ipv6-address and prefix-length are :: and 0, respectively.	Matches all the IPv6 routes whose prefix length is within the range from greater-equal to less-equal.	An IP prefix list cannot be configured if the prefix and mask do not match. For example: ip ipv6-prefix aa index 10 permit 1::1 0 greater-equal 5 less-equal 30 Error: Failed to add the address prefix list ::/0, because the destination address and mask do not match. Correct configuration: ip ipv6-prefix aa index 10 permit :: 0 greater-equal 5 less-equal 30 Matching result: The IPv6 routes whose prefix length is within the range from 5 to 30 are permitted.
Both greater-equal and less-equal exist.	The post-processing ipv6-address and prefix-length are :: and X (non-0 value), respectively.	Matches all the IPv6 routes whose prefix length is within the range from greater-equal to less-equal.	Pre-processing: ip ipv6-prefix aa index 10 permit ::1:1 96 greater-equal 120 less-equal 124 Post-processing: ip ipv6-prefix aa index 10 permit :: 96 greater-equal 120 less-equal 124 Matching result: The IPv6 routes whose prefix length is within the range from 120 to 124 are permitted.

AS_Path

An AS_Path filter is used to filter BGP routes based on AS_Path attributes contained in BGP routes. The AS_Path attribute is used to record in distance-vector (DV) order the numbers of all ASs through which a BGP route passes from the local end to the destination. Therefore, AS_Path attributes can be used to filter BGP routes.

The matching condition of an AS_Path is specified using a regular expression. For example, ^30 indicates that only the AS_Path attribute starting with 30 is matched. Using a regular expression can simplify configurations. For details about regular expressions, see Configuration Guide - Basic Configurations.

The AS_Path attribute is a private attribute of BGP and is therefore used to filter BGP routes only. For details about the AS_Path attribute, see BGP Fundamentals.

Community

A community filter is used to filter BGP routes based on the community attributes contained in BGP routes. The community attribute is a group of destination addresses with the same characteristics. Therefore, community attributes can be used to filter BGP routes.

In addition to the well-known community attributes, users can define community attributes using digits. The matching condition of a community filter can be specified using a community ID or a regular expression.

Like AS_Path filters, community filters are used to filter only BGP routes because the community attribute is also a private attribute of BGP. For details about the community attribute, see Community Attribute.

Large-community

A large-community filter is used to filter BGP routes based on large-community attributes contained in BGP routes. The large-community attribute is an extended community attribute. The community attribute is a group of destination addresses with the same characteristics and consists of a set of 4-byte values, each of which specifies a community. Generally, the community attribute on the NetEngine 8000 F is in the format of aa:nn, where aa specifies a 2-byte AS number and nn specifies the community attribute ID defined by an administrator. The community attribute is not flexible enough because it fails to carry a 4-byte AS number and contains only one community attribute ID. To address this problem, the large-community attribute can be used instead. The large-community attribute consists of a set of 12-byte values and is in the format of Global Administrator:LocalData1:LocalData2.

The large-community filter is used to filter only BGP routes because the large-community attribute is also a private attribute of BGP. For details about the large-community attribute, see Large-Community Attribute.

Extended Community

An extended community is used to filter BGP routes based on extended community attributes. BGP extended community attributes are classified as follows:

VPN target: A VPN target controls route learning between VPN instances, isolating routes of VPN instances from each other. A VPN target may be either an import or export VPN target. Before advertising a VPNv4 or VPNv6 route to a remote MP-BGP peer, a PE adds an export VPN target to the route. After receiving a VPNv4 or VPNv6 route, the remote MP-BGP peer compares the received export VPN target with the local import VPN target. If they are the same, the remote MP-BGP peer adds the route to the routing table of the local VPN instance.
Source of Origin (SoO): Several CEs at a VPN site may be connected to different PEs. The VPN routes advertised from the CEs to the PEs may be re-advertised to the VPN site where the CEs reside after the routes have traversed the backbone network, causing routing loops at the VPN site. In this situation, configure an SoO attribute for VPN routes. With the SoO attribute, routes advertised from different VPN sites can be distinguished and will not be advertised to the source VPN site, preventing routing loops.
Encapsulation: The encapsulation extended community attribute is classified as the VXLAN encapsulation extended community attribute or MPLS encapsulation extended community attribute. In EVPN VXLAN scenarios, EVPN routes carry the VXLAN encapsulation extended community attribute, and the value of this attribute can be set to 0:8 to filter EVPN routes. In EVPN MPLS scenarios, received EVPN routes do not carry the MPLS encapsulation extended community attribute in most cases. If a device receives EVPN routes with the MPLS encapsulation extended community attribute, the value of this attribute can be set to 0:10 to filter the routes.
Segmented-nh: The segmented-nh can be added to intra-AS I-PMSI A-D routes in an NG MVPN scenario where segmented tunnels are used.

The matching condition of an extended community can be specified using an extended community ID or a regular expression.

An extended community is used to filter only BGP routes because the extended community attribute is also a private attribute of BGP.

RD

An RD is used to filter BGP routes based on RDs in VPN routes. RDs are used to distinguish IPv4 and IPv6 prefixes in the same address segment in VPN instances. RD-specific matching conditions can be configured in an RD filter.

For details about how to configure an RD, see HUAWEI NetEngine 8000 F Series Router Configuration Guide – VPN.

Route-Policy

A route-policy is a complex filter. It is used to match attributes of specified routes and change route attributes when specific conditions are met. A route-policy can use the preceding six filters to define its matching rules.

Composition of a Route-Policy

As shown in the following figure, a route-policy consists of node IDs, matching modes, if-match clauses, apply clauses, and goto next-node clauses. The if-match, apply, and goto next-node clauses are optional.

Figure 1 Composition of a route-policy

Node ID
A route-policy can consist of multiple nodes. The method of specifying a node ID is the same as that of specifying an index for an IP prefix list. In a route-policy, routes are filtered based on the following rules:
- Sequential match: A device checks entries in ascending order by node ID. Specifying the node IDs in a required order is recommended.
- Unique match: The relationship among the nodes of a route-policy is "OR". If a route matches one node, the route matches the route-policy and will not be matched against a next node.
Matching mode
Either of the following matching modes can be used:
- permit: indicates the permit mode of a node. If a route matches the if-match clauses of the node in permit mode, the apply clauses of the node are executed, and the route will not be matched against a next node. If the route does not match the if-match clauses of the node, the device continues to match the route against a next node.
- deny: indicates the deny mode of a node. In deny mode, apply clauses are not executed. If a route matches all if-match clauses of the node, the route is rejected and is not matched against a next node. If the entry does not match if-match clauses of the node, the device continues to match the route against a next node.
To allow other routes to pass through, a route-policy that contains no if-match or apply clause in the permit mode is usually configured for a node after multiple nodes in the deny mode are configured.
if-match clause

The if-match clause defines the matching rules.

Each node of a route-policy can comprise multiple or none if-match clauses. By default, if the address family that a route belongs to does not match that specified in an if-match clause of a route-policy, the route matches the route-policy. Take a route-policy node in permit mode (permit node for short) as an example. If no if-match clause is configured for the permit node, all IPv4 and IPv6 routes are considered to match this node. If the permit node is configured with only an if-match clause for filtering IPv4 routes, IPv4 routes that match the if-match clause and all IPv6 routes are considered to match this node. If the permit node is configured with only an if-match clause for filtering IPv6 routes, IPv6 routes that match the if-match clause and all IPv4 routes are considered to match this node. This implementation also applies to a deny node.

You are not advised to use the same route-policy to filter both IPv4 and IPv6 routes by default. Otherwise, services may be interrupted in the following scenarios:
- For the same route-policy, some nodes apply only to IPv4 routes and some nodes apply only to IPv6 routes.
- A route-policy applies only to IPv4 routes but is used by IPv6 protocols.
- A route-policy applies only to IPv6 routes but is used by IPv4 protocols.
To use the same route-policy to filter both IPv4 and IPv6 routes, you can change the default behavior of the route-policy. When the address family that a route belongs to does not match that specified in an if-match clause of a route-policy, to set the default action of the route-policy to deny, run the route-policy address-family mismatch-deny command. Take a permit node as an example. If no if-match clause is configured for the permit node, all IPv4 and IPv6 routes are considered to match this node. If the permit node is configured with only an if-match clause for filtering IPv4 routes, only IPv4 routes that match the if-match clause are considered to match this node, and no IPv6 routes match this node. If the permit node is configured with only an if-match clause for filtering IPv6 routes, only IPv6 routes that match the if-match clause are considered to match this node, and no IPv4 routes match this node. This implementation also applies to a deny node.

If an if-match clause of a node uses information such as the next hop address or direct route source as a matching condition, the node compares the address family to which the next hop address or direct route source belongs with that specified in the if-match clause.
apply clause

The apply clauses specify actions. When a route matches a route-policy, the system sets some attributes for the route based on the apply clause.

Each node of a route-policy can comprise multiple apply clauses or no apply clause at all. No apply clause needs to be configured if routes are to be filtered but their attributes do not need to be set.

If if-match clauses are not configured in a route-policy but apply clauses are configured, the route-policy does not have any filtering conditions to match routes. In this case, if the matching mode of a route-policy node is set to permit, all routes are permitted and the apply clauses are executed; if the matching mode is set to deny, all routes are denied and the apply clauses are not executed.
goto next-node clause

goto next-node clauses further match routes against a specified node after the routes match the current node.

Matching results of a route-policy

The matching results of a route-policy are obtained based on the following aspects:

Matching mode of the node, either permit or deny
Matching rules (either permit or deny) contained in the if-match clause (such as ACLs or IP prefix lists)

Table 4 describes matching results.

**Table 4** Matching results of a route-policy
Rule (Matching Rule Contained in if-match Clauses)	Mode (Matching Mode of a Node)	Matching Result
permit	permit	Routes matching the if-match clauses of the node match the route-policy, and the matching is complete. Routes not matching the if-match clauses of the node continue to match against the next node of the route-policy.
permit	deny	Routes matching the if-match clauses of the node are denied by the route-policy, and the matching is complete. Routes not matching the if-match clauses of the node continue to match against the next node of the route-policy.
deny	permit	Routes matching the if-match clauses of the node are denied by the route-policy and continue to match against the next node. Routes not matching the if-match clauses of the node continue to match against the next node of the route-policy.
deny	deny	Routes matching the if-match clauses of the node are denied by the route-policy and continue to match against the next node. Routes not matching the if-match clauses of the node continue to match against the next node of the route-policy. NOTE: If all if-match clauses and nodes of the route-policy are in deny mode, all routes are rejected.

By default, all the routes that do not match the filtering conditions in a route-policy on the HUAWEI NetEngine 8000 F Series are rejected by the route-policy. If more than one node is defined in a route-policy, at least one of them must be in permit mode. The reason is as follows:

If a route fails to match any of the nodes, the route is denied by the route-policy.
If all the nodes in the route-policy are set in deny mode, all the routes to be filtered are denied by the route-policy.

Other Functions

In addition to the preceding functions, routing policies have an enhanced feature: BGP to IGP.

In some scenarios, when an IGP uses a routing policy to import BGP routes, route attributes, the cost for example, can be set based on private attributes, such as the community in BGP routes. However, without the BGP to IGP feature, BGP routes are denied because the IGP fails to identify private attributes, such as community attributes in these routes. As a result, apply clauses used to set route attributes do not take effect.

With the BGP to IGP feature, route attributes can be set based on private attributes, such as the community, extended community, and AS_Path attributes in BGP routes. The BGP to IGP implementation process is as follows:

When an IGP imports BGP routes through a route-policy, route attributes can be set based on private attributes, such as the community attribute in BGP routes.
If BGP routes carry private attributes, such as community attributes, the system filters the BGP routes based on the private attributes. If the BGP routes meet the matching rules, the routes match the route-policy, and apply clauses take effect.
If BGP routes do not carry private attributes, such as community attributes, the BGP routes fail to match the route-policy and are denied, and apply clauses do not take effect.