Solve the problem of multi-point bidirectional route re-publishing (route pruning)

Solve the problem caused by multi-point bidirectional route redistribution (route pruning) first look at which scenarios will use the two-way route redistribution scenario 1: The company has two technical directors, respectively managing the headquarters and divisions, the level is almost the same. Supervisor A thinks that the performance of the branch router on my side is poor, and the RIP Protocol is enough. The head of the Headquarters thinks that OSPF is better, and OSPF must be used. Due to comments, the Division uses RIP and the Headquarters uses OSPF, here we need to use two-way route redistribution to solve the problem of a company using two different routing protocols www.2cto.com Scenario 2: for large companies, we have acquired another company, the company used the OSPF protocol and the acquired company used the OSPF protocol. To prevent network interruptions caused by network redeployment, this leads to the need to use two-way re-distribution of routes for the integration of networks between two companies. Scenario 3: This is more biased, and may be due to business reasons, the company ran the RIP Protocol on some UNIX or linux systems and re-published routes to connect to other networks of the company (which is not very common). There are four types of re-released routes: single point bidirectional re-release Single Point unidirectional re-release multi point multi-direction re-release this blog article analyzes some problems arising from multi-point bidirectional re-release and solutions first build the entire environment (configure the interface address, enable routing, and do not post the configurations at the migrant workers level to avoid wasting the layout.) www.2cto.com implements bidirectional redistribution of RIP and OSPF on R1 (config) # router ripR1 (config-router) # redistribute ospf 1 metric 1 # note that metric must be added when other routing protocols are re-published in the distance vector routing protocols such as RIP and ospf, if this parameter is not added, the default value is infinite. When re-distributing data to RIP, note that it cannot exceed 15 because the maximum number of RIP hops is 16R1 (config) # router ospf 1 R1 (config-router) # redistribute rip subnets is also true on R3 R3 (config) # router ripR3 (config-router) # redistribute ospf 1 metric 1R3 (config) # router ospf 1R3 (config-router) # redistribute rip subnets view the route table of each router's route table R1 after re-publishing
R2 route table
Route table of R3
R4 route table
The following problems are found through comparison:
Problem 1: On R1, The 23.0.0.0/24 CIDR block should be an internal RIP route, but it is learned as an external OSPF route. Problem 1 also exists on R3. 2.2.2.0/24 and 12.0.0.0/24 should also be learned through RIP. Problem 2: On R4, the 2.2.2.0/24 CIDR block should have two exclusive exits. The load balancing through R1 and R3 only learns that the next hop is 124.0.0.1, here, we will analyze the causes of these two problems through a route entry through R1. www.2cto.com we know that the RIP management distance is 120, and the OSPF management distance is 110, the RIP management distance is higher than that of OSPF, And the router selects the one with the lower management distance first. The reason for the confusion of Route entries is that the management distance is generated. First, R1 learned the three routes 2.2.2.0/24, 12.0.0.0/24, and 23.0.0.0/24 through RIP before the route re-release is configured, on R3, we learned the three routes through RIP and configured the route redistribution, which makes things a little different .... First, I analyzed the problems on R3. First, I re-published the RIP and OSPF routes on R1. In this way, R1 will advertise the above three routes through OSPF type2, that is, the OE2 seen on the route table from F0/0, then R3 and R4 receive the route information (OSPF should say that the database is synchronized... Let's talk about the image here ...), Then R3 began to become silly, because the above three routes learned from both RIP and OSPF, and then compared to the management distance, it is found that OSPF is smaller than RIP, so we chose the one we learned through OSPF and abandoned RIP .... On R1, the same principle is used to analyze the problem of Server Load balancer on R4. the culprit is to look at the 2.2.2.0/24 route in the same way as on R1 and R2. In OSPF, because I did two-way re-release on R1 first. Therefore, this route is advertised through OSPF on R1, and R4 naturally learns this route. After learning this route on R3, The 2.2.2.0/24 learned in RIP is discarded by comparing the Management Distance, so the route advertised on R3 is the one learned on R1, And the next hop of this route is R1, so R4 only receives the next hop as the R1 route. This may be a bit messy. R3 thinks that the next hop of the route to 2.2.2.0/24 is R1. In this case, the OSPF Database Synchronization Mechanism, on R4, the next hop of this route should also be the re-distribution of routes like R1, leading to route chaos and loops, we need to optimize and improve the network through route pruning. Solution: 1. Use the release list. In the list, we need to write each route to be filtered. This is more troublesome for the above environment, here, we use the release list method to trim routes. First, we define the access control list and capture the three routes in RIP to R1 (config) # ip access-list standard DenyFromO2R # name-based access control lists should be used whenever possible during access control lists. When there are many ACLs, names should be better differentiated, here the name consciousness is to block entries from OSPF to RIP www.2cto.com R1 (config-std-nacl) # deny 12.0.0.0 0.0.255 R1 (config-std-nacl) # deny 23.0.0.0 0.0.0.255 R1 (config-std-nacl) # deny 2.2.2.0 0.0.0.255 R1 (config-std-nacl) # permit any
Then enter R1 (config) # router ripR1 (config-router) # distribute-list DenyFromO2R in fastEthernet 0/0 in OSPF. # the reasons described above are as follows, this command defines the rules for re-publishing and trimming under OSPF, and blocks the three routes defined in the ACL from re-publishing from OSPF. Note that when using the release list in OSPF, you are not allowed to use the OUT statement. You can only use the in statement. Configure R3 (config) # ip access-list standard DenyFromO2R R3 (config-std-nacl) # deny 12.0.0.0 0.0.255 R3 (config-std-nacl) in R3) # deny 23.0.0.0 0.0.0.255 R3 (config-std-nacl) # deny 2.2.2.0 0.0.0.255 R3 (config-std-nacl) # permit anyR3 (config) # router ripR3 (config-router) # distribute-list DenyFromR2O in fastEthernet 0/0 OK. Check the route table.

R2 route table

Route table of R3

R4 route table
As you can see, the current route is normal, and R1 routes to 124.0.0.0/24 and R4 routes to 2.2.2.0/24 also implement Load Balancing www.2cto.com 2: we can see that the previous route chaos occurs because the Routes learned through RIP are re-published into OSPF, and OSPF is re-released to RIP, on R1 and R3, the same route is learned from two different protocols, and the OSPF route is selected. The solution is to re-release the route from RIP to OSPF, that is, to set the Management Distance of the OSPF external route to a greater value than RIP. First, let's look at the Management Distance of the following commonly used routing protocols: 90. External routes of the OSPF instance: 170RIP: 120the internal and external routes of OSPF are both 110. We first define the external routes of OSPF (through ACL ), in OSPF, set the Management Distance of this part of external routes to 121. First, define the external routes of OSPF. R1 (config) # ip access-list standard FromR3 # define the OSPF external route R1 (config-std-nacl) learned from R3 on R1) # permit 12.0.0.0 0.0.255 R1 (config-std-nacl) # permit 23.0.0.0 0.0.0.255 R1 (config-std-nacl) # permit 2.2.2.0 0.0.0.255R3 (config) # ip access-list standard FromR1 # define the OSPF external route R3 (config-std-nacl) learned from R1 on R3) # permit 12.0.0.0 0.0.255 R3 (config-std-nacl) # permit 23.0.0.0 0.0.0.255 R3 (config-std-nacl) # permit 2.2.2.0 0.0.0.255 R1 (config) # router ospf 1 R1 (config-router) # distance 121 3.3.3.3 0.0.0.0 FromR3 # indicates the route learned from Router-id 3.3.3.3, set the Management distance of the routes in the list to 121 R3 (config) # router ospf 1 R3 (config-router) # distance 121 1.1.1.1 0.0.0.0 FromR1 to view the route table of R3

It is shown that the routes 2.2.2.0/24 and 12.0.0.0/24 are learned from RIP. Check the external routing database www.2cto.com of OSPF.

It is found that the database still contains data information of 2.2.2.0/24 and 12.0.0.0/24. However, because the Management Distance of these routes is higher than that of RIP, therefore, the same is true for the RIP Protocol R1 selected in the routing table. In R4, view the route table

We can see the complete routing of the three CIDR Blocks 12, 23, and 2. Here we list the solution in 2, you can also use tools such as route-map to trim route entries when re-publishing a route, as long as you know the principle and mechanism of the entire route, these methods are just the tools you have chosen.
Author: lustlost