Hello, everybody!

This post is about Route-Policy. Please see more information below.

1      Route-Policy

A route-policy is a complicated filter, which can match route attributes and change route attributes when conditions are met. The following describes a route-policy, including its components, matching rules, and applications.

1.1  Components

In Figure 2-1, a route-policy consists of node ID, matching mode, if-match clause (condition clause), and apply clause (action statement).

Components of a route-policy

l   Node ID

A route-policy can contain multiple nodes. Routes must follow the following rules when matching a route-policy:

(1)      Sequential match: The system checks routing entries against nodes in ascending order of node ID. Therefore, you need to specify node IDs in the required sequence.

(2)      Unique match: The relationship between all nodes in a route-policy is "OR". This means that if a route matches one node in a route-policy, the route matches this route-policy and does not need to match the other nodes in this route-policy.

l   Matching mode

Two node matching modes are available: permit and deny.

(1)      permit: If a route matches a node, the actions defined by the apply clauses of this node are performed on this route, and the system does not match this route against the next node. If a route does not match a node, the system matches this route against the next node.

(2)      deny: If a route matches all the if-match clauses of a node, this route is denied by this node, the system does not match this route against the next node, and the actions defined by the apply clauses of this node will not be performed on this route. If a route does not match the apply clauses of a node, the system matches this route against the next node.

Precautions

A route-policy in permit mode that does not contain if-match and apply clauses is often set behind multiple deny nodes to allow other routes to pass through.

l   if-match clause (condition statement)

if-match clauses define matching conditions. Each node in a route-policy can contain multiple or no if-match clauses. If a permit node does not contain any if-match clause, this node matches all routes.

l   apply clause (action statement)

apply clauses define actions. When routes are filtered against a route-policy, the system sets attributes for the routes according to the actions defined by apply clauses. Each node in a route-policy can contain multiple or no apply clauses. If you only need to filter routes but do not need to set attributes for routes, apply clauses do not need to be used.

1.2  Matching Rules

When using a route-policy, you may wonder whether a route is permitted or denied after this route matches a route-policy. The result may directly affect services. Actually, the result depends on the matching rules of the route-policy.

The matching rules of each node in a route-policy depend on the following factors:

Matching mode of the node in the route-policy: permit or deny

Matching conditions (permit or deny) defined by if-match clauses (for example, IP prefix list or ACL) of the node

The following table describes possible matching results for each node.

Matching rules of a route-policy

Among the preceding four combinations, the first two combinations are easy to understand and commonly used. The last two combinations are a little difficult to understand, and the following example describes the third combination for your reference.

Assume that the matching condition of if-match clauses in a node is deny and the matching condition of this 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  //Permit 172.16.16.0

#

route-policy RP permit node 10    //In this node, the route 172.16.16.0 is denied and the system matches it against the next node.

 if-match acl 2001

#

route-policy RP permit node 20     //In this node, the route 172.16.16.0 is permitted.

 if-match acl 2002

#

In this situation, the route 172.16.16.0 is denied by node 10 and then the system matches this route against the next node. This route is then permitted by node 20 and is permitted by this route-policy.

Precautions

All unmatched routes on Huawei S switches are denied by a route-policy by default. If more than one node is defined in a route-policy, at least one of them must be in permit mode. When a route-policy is used to filter routes:

l   If a route does not match any node, this route is denied by this route-policy.

l   If all the nodes in the route-policy are in deny mode, all the routes to be filtered are denied by this route-policy.

1.3  Applications

The following section describes applications of a route-policy.

Using a route-policy for traffic distribution

User requirements

In Figure 2-2, a campus network is divided into the production network segment and office network segment. When terminals connected to LSW3 access the following network segments, the traffic model is as follows:

l   10.10.1.0/24: production network segment: Traffic is first transmitted by LSW1, and the link that passes through LSW2 functions as the backup link.

l   10.10.2.0/24: office network segment: Traffic is first transmitted by LSW2, and the link that passes through LSW1 functions as the backup link.

l   10.10.3.0/24: other network segment: Traffic is load balanced between the two links that pass through LSW1 and LSW2 respectively.

The preceding traffic model ensures that traffic of the production network is separated from traffic of the office network, facilitating maintenance and fault location. This traffic model facilitates traffic load balancing between two links working in backup mode, ensuring network stability.

Configuration process:

Establish OSPF neighbor relationships between LSW1, LSW2, and LSW3.

On LSW1 and LSW2, configure static routes to the preceding three network segments and import these static routes into OSPF to advertise them to LSW3.

Configure a route-policy on LSW1 and LSW2 to adjust the traffic model to meet user requirements.

The following provides only the route-policy configuration.

The key configuration of LSW1 is as follows:

#

acl number 2000    

 rule 5 permit source 10.10.1.0 0 //Match the route to the production network segment.

#

acl number 2001    

 rule 5 permit source 10.10.2.0 0 //Match the route to the office network segment.

#

route-policy RP permit node 10

 if-match acl 2000

 apply cost 10                        //Set the cost of the route to the production network segment to 10.

#

route-policy RP permit node 20   

 if-match acl 2001

 apply cost 20                        //Set the cost of the route to the office network segment to 20.

#

route-policy RP permit node 30    //Permit the routes to the remaining network segment.

#

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

#

The key configuration of LSW2 is as follows:

#

acl number 2000

 rule 5 permit source 10.10.1.0 0  //Match the route to the production network segment.

#

acl number 2001

 rule 5 permit source 10.10.2.0 0  //Match the route to the office network segment.

#

route-policy RP permit node 10    

 if-match acl 2000

 apply cost 20                        //Set the cost of the route to the production network segment to 20.

#

route-policy RP permit node 20    

 if-match acl 2001

 apply cost 10                        //Set the cost of the route to the office network segment to 10.

#

route-policy RP permit node 30     //Permit the routes to the remaining network segment.

#

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

#

Verification

After the preceding configurations are complete, check the IP routing table of LSW3 to determine 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

The preceding command output shows that traffic to the production network segment 10.10.1.0/24 is first transmitted by LSW1, traffic to the office network segment 10.10.2.0/24 is first transmitted by LSW2, and traffic to the remaining network segments is load balanced between two links that pass through LSW1 and LSW2 respectively. This indicates that the traffic model meets user requirements.

This section describes the components, matching rules, and applications of a route-policy. In this section, ACLs are mainly used to match routes. The following section describes an IP prefix list, which is more accurate in matching routes.

For more details, click the following hyperlink: