Understanding Routing Policies
Overview of Routing Policies
- 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 switch provides multiple types of filters for routing policies. Table 10-1 lists the filters supported by the device and their application scopes and matching conditions.
Filter |
Application Scope |
Matching Rules |
|---|---|---|
Dynamic routing protocols |
Inbound interface, source or destination IP address, protocol type, and source or destination port number |
|
Dynamic routing protocols |
Source and destination IP addresses and next hop address |
|
BGP |
AS_Path attribute |
|
BGP |
Community attribute |
|
VPN |
Extended community attribute |
|
VPN |
RD attribute |
|
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, and RD. |
The ACL, IP prefix list, AS_Path 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.
- 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.
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.
- 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.
- 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.
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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 AS_Path attribute is a private attribute of BGP and is therefore used to filter BGP routes only.
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.
Extended Community
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.
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.
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
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. 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. 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.
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
- 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)
Rule (Matching Rule Contained in if-match Clauses) |
Mode (Matching Mode of a Node) |
Matching Result |
|---|---|---|
permit |
permit |
|
deny |
|
|
deny |
permit |
|
deny |
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 device 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.