Still don’t understand routing strategy? Let’s analyze it!

Still don’t understand routing strategy? Let’s analyze it!

For IP network engineers, the deployment of routing strategies can be seen everywhere, whether in carrier IP networks or enterprise networks, the application of routing strategies is very common. At the same time, in network planning, routing strategy planning is also a core content. In order to help everyone better master and apply routing strategies, we have launched the topic of routing strategies. We hope that this topic can serve as a starting point for discussion and learning.

1. Routing Strategy Overview

1. What is a routing policy?

When we discuss something, we usually can’t avoid the question: “What is XXX?” Here we also try to define routing strategy to answer the question: “What is routing strategy?”

Many people equate routing strategy with route-policy, and some people may say that filter-policy also belongs to the category of routing strategy. In fact, these understandings are a bit inaccurate. In fact, routing strategy is not a specific technology, nor a specific feature.

Routing policy is a "strategy" that uses a series of tools or methods to control routing. This policy can affect the generation, release, and selection of routes, and thus affect the forwarding path of packets. These tools include ACL, route-policy, ip-prefix, filter-policy, etc. These methods include filtering routes, setting routing attributes, etc.

2. Calling relationship between routing strategy tools

When discussing routing policies, we often come across many tools, such as ACL, route-policy, ip-prefix, filter-policy, etc. Many people are confused by the calling relationship between them, and always feel that there is an unclear relationship between them. Here we use a picture to introduce the relationship between them.

Figure 1 Calling relationship between routing strategy tools

As shown in Figure 1, we divide all tools into three categories:

  • Conditional tool: used to "grab" the required routes.
  • Policy tool: used to perform certain actions on the "captured" routes, such as allowing, denying, modifying attribute values, etc.
  • Calling tool: used to apply routing policies to a specific routing protocol to make them effective.

The filter-policy and peer in the calling tool have their own policy tool functions, so these two tools can directly call the condition tool. Other calling tools must indirectly call the condition tool through route-policy.

Note that peers cannot call ACL, but can call all other conditional tools.

3. What is the use of routing strategy?

In IP networks, routing policies are used in two main ways: 1) Filtering routing information. 2) Modifying routing attributes. For details, see Table 1:

Table 1 Routing policy functions

If you think that the role of routing policy is a bit abstract, it doesn't matter. Let's take a practical example to explain it and you will understand it. Filter routing information through routing policy:

Figure 1 Filtering routing information through routing policies

As shown in Figure 1, SwitchA is a dual-uplink network structure. SwitchA receives routes from SwitchB and SwitchC. If SwitchA only wants to receive routes from SwitchB but not from SwitchC, what should it do? In this case, you can consider configuring a routing policy on SwitchA to allow routes from SwitchB and reject routes from SwitchC. Modify route attributes through routing policies

Figure 2 Modifying route attributes through routing policies

As shown in Figure 2, SwitchA also has a dual-uplink network structure. However, since the link on SwitchB is more stable and has a larger bandwidth, the user wants to use the link on SwitchB as the primary link and the link on SwitchC as the backup link. When the primary link fails, the traffic automatically switches to the backup link. In this scenario, you can use routing policies to reduce the route cost value from SwitchB and increase the route cost value from SwitchC. In this way, the traffic will automatically select the link on SwitchB as the primary link and the link on SwitchC as the backup link, realizing the primary and backup of the route.

2. Routing strategy and policy routing

1. Differences between routing policies and policy routing

When I first encountered routing policy and policy routing, I was scratching my head and couldn't tell them apart. I kept wondering why the protocol developers gave them such confusing names. Wouldn't it be easier to confuse them if they changed the names? But since the names have been used for so many years, you may not be able to tell them apart, but you are familiar with them. Although the feature of policy routing is not within the scope of this topic, we will also compare and analyze these two twin brothers here so that everyone will not be confused.

(1) Routing strategy

The operation object of routing policy is routing information. Routing policy mainly implements functions such as routing filtering and routing attribute setting. It changes the path of network traffic by changing routing attributes (including reachability).

(2) Policy Routing

The operation object of policy routing is the data packet. When the routing table has been generated, the data packet is not forwarded according to the routing table, but the data packet forwarding path is changed according to a certain strategy as needed.

Therefore, it can be seen that policy routing takes effect before the routing table. If a message matches the policy routing, the message will not check the routing table again, but will be forwarded directly according to the "guidance" of the policy routing. Therefore, policy routing is a "guy" that does not follow the routine, and because of this, the application of policy routing will be more flexible.

2. Comparative analysis of routing strategies and policy-based routing

In order to make a more specific comparison between routing strategy and policy routing, we make a comprehensive comparison between the two through Table 2.

Table 2 Comparative analysis of routing strategies and policy routing

3. Try out the routing strategy

The above introduces some basic knowledge about routing policies at a macro level. Do you still feel a little unsatisfied? Do you still not feel the power of routing policies? It doesn't matter. Next, let's take a look at an example of implementing routing filtering through routing policies as a small test. This example involves concepts such as ACL, ip-prefix, route-policy, and filter-policy. We will introduce them in detail in the following special topics. You just need to understand what routing policies can do first, and don't study them too deeply to avoid being obsessed!

Figure 3 Example of implementing route filtering through routing policy

As shown in Figure 3, in the network running the OSPF protocol, SwitchA receives routes from the Internet and provides Internet routes for the OSPF network. Now the user hopes that the OSPF network only receives the three external routes 172.16.16.0/24, 172.16.17.0/24, and 172.16.18.0/24, and does not receive other external routes.

The above user needs can be achieved in many ways. Next, we give two common implementation methods for your reference.

In the following experiment, we configure a black hole route in SwitchA as a test route and introduce static routes in OSPF to simulate receiving routes from the Internet. The key configurations on SwitchA are as follows:

 #
ospf 1
import - route static
area 0.0 .0 .0
network 192.168 .1 .0 0.0 .0 .255
#
ip route - static 172.16 .16 .0 255.255 .255 .0 NULL0
ip route - static 172.16 .17 .0 255.255 .255 .0 NULL0
ip route - static 172.16 .18 .0 255.255 .255 .0 NULL0
ip route - static 172.16 .19 .0 255.255 .255 .0 NULL0
ip route - static 172.16 .20 .0 255.255 .255 .0 NULL0
#

1. Implement route filtering through ACL+route-policy

(1) Define ACL 2000 to match the routes that need to be allowed.

 [ SwitchA ] acl 2000
[ SwitchA - acl - basic - 2000 ] rule 5 permit source 172.16 .16 .0 0
[ SwitchA - acl - basic - 2000 ] rule 10 permit source 172.16 .17 .0 0
[ SwitchA - acl - basic - 2000 ] rule 15 permit source 172.16 .18 .0 0
[ SwitchA - acl - basic - 2000 ] quit

(2) Create a route-policy named RP, configure a node numbered 10, and call ACL2000.

 [ SwitchA ] route - policy RP permit node 10
[ SwitchA - route - policy ] if - match acl 2000

(3) This route-policy is called when OSPF imports static routes

 [ SwitchA ] ospf 1
[ SwitchA - ospf - 1 ] import - route static route - policy RP
[ SwitchA - ospf - 1 ] quit

Because the route-policy implicitly contains the deny node by default, the routes 172.16.19.0 and 172.16.20.0 are not introduced into OSPF because they do not satisfy the if-match statement.

After configuring the above routing policy, the routing table of SwitchB is as follows:

 [ SwitchB ] display ip routing - table

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

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -

Routing Tables : Public

Destinations : 7 Routes : 7

Destination / Mask Proto Pre Cost Flags NextHop Interface

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
172.16 .16 .0 / 24 O_ASE 150 1 D 192.168 .1 .1 Vlanif10
172.16 .17 .0 / 24 O_ASE 150 1 D 192.168 .1 .1 Vlanif10
172.16 .18 .0 / 24 O_ASE 150 1 D 192.168 .1 .1 Vlanif10
192.168 .1 .0 / 24 Direct 0 0 D 192.168 .1 .2 Vlanif10
192.168 .1 .2 / 32 Direct 0 0 D 127.0 .0 .1 Vlanif10

You can see that after the routing policy is configured on SwitchA, only three external routes, 172.16.16.0/24, 172.16.17.0/24, and 172.16.18.0/24, appear in the IP routing table of SwitchB. Other external routes are gone.

2. Implement route filtering through ip-prefix+filter-policy

(1) Define an address prefix list to match the routes that need to be allowed.

 [ SwitchA ] ip ip - prefix huawei index 10 permit 172.16 .16 .0 24
[ SwitchA ] ip ip - prefix huawei index 20 permit 172.16 .17 .0 24
[ SwitchA ] ip ip - prefix huawei index 30 permit 172.16 .18 .0 24

(2) In the OSPF view of SwitchA, use filter-policy to filter the advertised routes.

 [ SwitchA ] ospf 1
[ SwitchA - ospf - 1 ] filter - policy ip - prefix huawei export
[ SwitchA - ospf - 1 ] quit

Because the deny node is implicitly included in ip-prefix by default, the routes 172.16.19.0 and 172.16.20.0 are not within the range allowed by ip-prefix. Therefore, when SwitchA advertises routes to SwitchB, it only advertises the routes within the range allowed by ip-prefix and does not advertise other routes.

After the above configuration is completed, the routing table of SwitchB is as follows:

 [ SwitchB ] display ip routing - table

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

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -

Routing Tables : Public

Destinations : 7 Routes : 7


Destination / Mask Proto Pre Cost Flags NextHop Interface


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
172.16 .16 .0 / 24 O_ASE 150 1 D 192.168 .1 .1 Vlanif10
172.16 .17 .0 / 24 O_ASE 150 1 D 192.168 .1 .1 Vlanif10
172.16 .18 .0 / 24 O_ASE 150 1 D 192.168 .1 .1 Vlanif10
192.168 .1 .0 / 24 Direct 0 0 D 192.168 .1 .2 Vlanif10
192.168 .1 .2 / 32 Direct 0 0 D 127.0 .0 .1 Vlanif10

It can be seen that after the route filter-policy is configured on SwitchA, only three external routes, 172.16.16.0/24, 172.16.17.0/24, and 172.16.18.0/24, appear in the IP routing table of SwitchB. Other external routes are gone.

From the experimental results, the above two methods use different tools and methods, but the results are the same. I believe you have already seen that routing strategy is indeed not directly equivalent to route-policy, right? In fact, routing strategy is a series of means to control routing. The use of routing strategy may be different combinations of multiple tools such as ACL, route-policy, ip-prefix, filter-policy, etc. The above examples only list two of the more common combinations.

<<:  It’s no exaggeration, there would be no optical communication without optical modules!

>>:  GitHub requires two-factor authentication for all accounts!

Recommend

Wi-Fi 6: What's different and why does it matter?

Wi-Fi 6 is the next generation wireless standard ...

Qianjia Viewpoint | Simplifying Smart Cities

Challenges facing smart cities When designing a s...

This article explains OSPF clearly.

[[426836]] OSPF OSPF is an IGP and a Link-State p...

How will the emergence of 5G affect AI federated learning?

As development teams scramble to build AI tools, ...

F5 Future

[51CTO.com original article] Expert introduction:...

...

Talk about what you want to know and don't know about SDN

SDN has been very popular for a while. For a whil...

Discussion on 5G network construction plan

Labs Summary This paper proposes a 5G network arc...

"Innovation City" shines brightly and opens up a new ecosystem for Ascend

[[337542]] On August 11, 2020, the DevRun Develop...

Report: Global 5G RAN market shows strong growth

Global demand for 5G RAN is expected to grow at a...

With the support of celebrities, how fast can 5G run?

With the freezing of 5G 1.0 version, the first co...

Regarding the ocean, we actually have a choice...

There are ten thousand ways for us to live in pea...