Regarding Route-Policy, this article explains it in detail and you will understand it after reading it once!

In the previous issue of "Route Policy", we mentioned that many people equate route policy with Route-Policy. Although this is not quite accurate, it reflects the importance and universality of Route-Policy. Route-Policy is a relatively complex filter that can not only match certain attributes of route information, but also change the attributes of route information when conditions are met. In this issue, we will introduce Route-Policy in detail, including the composition, matching rules and usage examples of Route-Policy.

1. Route-Policy components

As shown in Figure 1, Route-Policy consists of four parts: node number, matching pattern, if-match clause (conditional statement) and apply clause (execution statement).

Figure 1 Route-Policy components

(1) Node number

A Route-Policy can consist of multiple nodes. Routes matching Route-Policy follow the following two rules:

• Sequential matching: During the matching process, the system checks each table item in ascending order of node number. Therefore, when specifying the node number, pay attention to the expected matching order.
• Unique match: The node numbers of Route-Policy are in an "or" relationship. As long as one node is matched, it is considered to have passed the filter and no other nodes are matched.

(2) Matching pattern

There are two node matching modes: permit and deny.

• permit specifies the node's matching mode as permit. When a route item passes the filtering of this node, the apply clause of this node will be executed without entering the next node; if the route item does not pass the filtering of this node, it will enter the next node to continue matching.
• deny specifies that the matching mode of the node is deny. In this case, the apply clause will not be executed. When the route item meets all the if-match clauses of the node, it will be denied to pass through the node and will not enter the next node; if the route item does not meet the if-match clause of the node, it will enter the next node to continue matching.

Note: Usually, a permit mode Route-Policy without if-match clause and apply clause is set after multiple deny nodes to allow all other routes to pass.

(3) if-match clause (conditional statement)

The if-match clause is used to define some matching conditions. Each node of Route-Policy can contain multiple if-match clauses or no if-match clauses. If a permit node is not configured with any if-match clause, the node matches all routes.

(4) Apply clause (execution statement)

The apply clause is used to specify an action. When a route is filtered by Route-Policy, the system sets some attributes of the route information according to the action specified by the apply clause. Each node of Route-Policy can contain multiple apply clauses or no apply clause. If you only need to filter routes and do not need to set route attributes, do not use the apply clause.

2. Routing policy matching results

I believe that when you use or learn Route-Policy, you will focus on the following question: for a route, after using Route-Policy, will the final result be to allow or deny this route? This final result has a great impact on the business, and may directly affect whether a certain business is available or not. This involves the issue of Route-Policy matching rules, which we will discuss in detail here.

The filtering result of each node of Route-Policy should be based on the following two points:

• The matching mode (permit or deny) of the node of Route-Policy.
• The match condition (permit or deny) contained in the if-match clause (such as the referenced address prefix list or access control list).

For each node, the combination of the above two points will result in the four situations shown in Table 1.

Table 1 Route-Policy matching rules

Note 1: Rule indicates whether the matching mode contained in the if-match clause is permit or deny.

Note 2: Mode indicates whether the matching mode corresponding to the node in Route-Policy is permit or deny.

Among the above four combinations, the first two are easier to understand and more commonly used. The last two are a little harder to understand. Here we take the third case as an example to illustrate:

Assume that the match condition contained in the if-match clause is deny, and the match condition corresponding to the node is permit. The configuration is as follows:

 #
 acl number 2001
 Rule 5 deny source 172.16.16.0 0 // Deny 172.16.16.0
 #
 acl number 2002
 Rule 5 permit source 172.16.16.0 0 // Allow 172.16.16.0
 #
 route - policy RP permit node 10 //At this node, the route 172.16.16.0 is rejected. Continue down
 if - match acl 2001
 #

 route - policy RP permit node 20 //At this node, the route 172.16.16.0 is permitted
 if - match acl 2002
 #

In this case, a key point is that at node 10, the route 172.16.16.0 is rejected, and the route will continue to match downwards. Maybe the next node will allow it to pass? Sure enough, when it continues to go down to node 20, 172.16.16.0 is allowed again, so the final matching result of Route-Policy is to allow the route 172.16.16.0.

Note:

If more than one node is defined in Route-Policy, it should be ensured that at least one of the nodes has a matching mode of permit. This is because Route-Policy is used for routing information filtering:

• If a certain routing information does not pass through any node, it is considered that the routing information does not pass the Route-Policy.
• If all nodes of a Route-Policy are in deny mode, no routing information can pass through the Route-Policy.

3. Routing policy use cases

In the above two sections, we have introduced the composition and matching rules of Route-Policy. In this section, we will look at an example of using Route-Policy.

Figure 2 Example of using Route-Policy to implement data diversion

(1) User needs

As shown in Figure 2, a campus network is mainly divided into production network segment and office network segment. When the terminal connected to LSW3 accesses the following network segment, the traffic model is as follows:

• 10.10.1.0/24-----Production network segment, preferentially go out through LSW1, and LSW2 is used as a backup link. (Welcome to follow the official account: Network Engineer A-Long)
• 10.10.2.0/24-----Office network segment, preferentially goes out through LSW2, and LSW1 serves as the backup link.
• 10.10.3.0/24-----Other network segments, you can use any network segment, just share the load.

This traffic model can ensure the separation of traffic between the production network and the office network, which is convenient for maintenance and fault location. At the same time, this traffic model is conducive to the balanced distribution of traffic to the two links, and at the same time, they serve as backup links for each other, which is conducive to the stability of the network.

(2) Configuration process

• An OSPF neighbor relationship is established between LSW1, LSW2, and LSW3.
• Configure static routes to the network segment on LSW1 and LSW2, import them into OSPF, and then advertise them to LSW3.
• Configure routing policies on LW1 and LSW2, and adjust the traffic model to meet user planning needs. (Welcome to follow the official account: Network Engineer A-Long)

Here we only provide the key configurations related to routing policies:

LSW1 key configuration:

 #
 acl number 2000
 rule 5 permit source 10.10 .1 .0 0 //Used to match the production network segment route
 #
 acl number 2001
 rule 5 permit source 10.10.2.00 //Used to match the office network segment route
 #
 route - policy RP permit node 10
 if - match acl 2000
 apply cost 10 //Set the cost value of the production network segment route to 10

 #
 route - policy RP permit node 20
 if - match acl 2001
 apply cost 20 //Set the cost value of the office network segment route to 20

 #
 route - policy RP permit node 30 // Allow the routes of the remaining network segments to come in without any processing
 #
 ip route - static 10.10 .1 .0 255.255 .255 .0 192.168 .14 .2
 ip route - static 10.10 .2 .0 255.255 .255 .0 192.168 .14 .2
 ip route - static 10.10 .3 .0 255.255 .255 .0 192.168 .14 .2
 # 

LSW2 key configuration:

 #
 acl number 2000
 rule 5 permit source 10.10 .1 .0 0 //Used to match the production network segment route
 #
 acl number 2001
 rule 5 permit source 10.10.2.00 //Used to match the office network segment route

 #
 route - policy RP permit node 10
 if - match acl 2000
 apply cost 20 //Set the cost value of the production network segment route to 20

 #
 route - policy RP permit node 20
 if - match acl 2001
 apply cost 10 //Set the cost value of the office network segment route to 10
 #
 route - policy RP permit node 30 // Allow the routes of the remaining network segments to come in without any processing
 #
 ip route - static 10.10 .1 .0 255.255 .255 .0 192.168 .25 .2
 ip route - static 10.10 .2 .0 255.255 .255 .0 192.168 .25 .2
 ip route - static 10.10 .3 .0 255.255 .255 .0 192.168 .25 .2
 # 

() Result verification

After completing the above configuration, you can view the IP routing table on LSW3 to confirm whether the traffic model is correct.

 < LSW3 > display ip routing - table

 Route Flags : R - relay , D - download to fib

 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 Routing Tables : Public

 Destinations : 9 Routes : 10


 Destination / Mask Proto Pre Cost Flags NextHop Interface


 10.10 .1 .0 / 24 O_ASE 150 10 D 192.168 .13 .1 Vlanif13
 10.10 .2 .0 / 24 O_ASE 150 10 D 192.168 .23 .1 Vlanif23
 10.10 .3 .0 / 24 O_ASE 150 1 D 192.168 .23 .1 Vlanif23
 O_ASE 150 1 D 192.168 .13 .1 Vlanif13
 127.0 .0 .0 / 8 Direct 0 0 D 127.0 .0 .1 InLoopBack0
 127.0 .0 .1 / 32 Direct 0 0 D 127.0 .0 .1 InLoopBack0
 192.168 .13 .0 / 24 Direct 0 0 D 192.168 .13 .2 Vlanif13
 192.168 .13 .2 / 32 Direct 0 0 D 127.0 .0 .1 Vlanif13
 192.168 .23 .0 / 24 Direct 0 0 D 192.168 .23 .2 Vlanif23
 192.168 .23 .2 / 32 Direct 0 0 D 127.0 .0 .1 Vlanif23

From the routing table of LSW3, we can see that traffic to the production network segment 10.10.1.0/24 preferentially goes through LSW1, traffic to the office network segment 10.10.2.0/24 preferentially goes through LSW2, and traffic to other network segments is load-balanced on the two links LSW1 and LSW2. The traffic model is in line with expectations.

Through this topic, we have basically explained the composition structure and matching rules of Route-Policy, and also let everyone understand the usage scenarios and configuration methods of Route-Policy through an example. In this topic, we mainly used ACL to "capture" the required routes. In fact, the address prefix list (ip ip-prefix) will be more accurate in "capturing" routes. We will introduce this in detail in the next issue of the route policy topic.