A routing loop occurs after routes are summarized on an AR2240

13

Root cause: On the live network, whether packets sent from Router2 to 192.168.128.161 through Router1 or ME60B depends on the 24GE card connected between Router1 and Router2. The 24GE card is the high-end LAN card that provides the route forwarding function (enabled by default), but cannot download a complete IP routing table. Router1 learns routes to 192.168.128.160/29 through OSPF. When packets reach Router1, Router1 sends the packets to Router2, causing a loop. To eliminate the loop, disable the route forwarding function of the high-end LAN card. Subsequently, packets received by the high-end LAN card are sent to the sub-core CPU for forwarding.
Run the set workmode lan-card l3centralize command in the system view to disable the route forwarding function of high-end LAN card. In this case, Router2 can ping 192.168.128.161 successfully.
Procedure:
1. Check route table and forwarding entries.
2. Perform tracert starting from R3.
3. Run the display traffic policy statistics interface interface-type interface-number { inbound | outbound } command on R1 and R2 respectively to collect traffic statistics on the interfaces that connect R1 and R2.
For details, see A Routing Loop Occurs After Routes Are Summarized on an AR2240.

Other related questions:
Routing blackhole occurs when OSPF and IS-IS import routes from each other
When OSPF and IS-IS import routes to each other, packets cannot be forwarded based on routes due to the sequence of configuration operations and route convergence. To solve the problem, perform the following operations: 1.When routes of routing protocols are distributed, filter imported routes to prevent loops. 2. When routes of routing protocols are imported, the route priority changes. Notice the route selection change due to imported routes and take measures to control routes. For details, see Routing Blackhole Occurs When OSPF and IS-IS Import Routes From Each Other.

Why cannot OSPF inter-area route summarization take effect
According to RFC 2328, the inter-area Type-3 link-state advertisements (LSAs) generated by an Area Border Router (ABR) are directly processed into corresponding Type-3 LSAs regardless of the configured range. Summarization configuration is considered only in the case of intra-area routes. Such route aggregation, even if achieved, causes more LSAs to be advertised to the backbone area, making the network unstable.

Why is the number of routes in the routing table inconsistent with the number of FIB entries after a required route iteration on an S series switches
Q: Why is the number of routes in the routing table inconsistent with the number of FIB entries after a required route iteration? A: After routes are iterated as required, routes of multiple outbound interfaces are not generated and there is only one route with multiple outbound interfaces. This route is iterated to multiple routes when delivered to the FIB. As a result, the number of routes in the routing table is inconsistent with the number of FIB entries. Among the route flags, R indicates that the route is iterated, and D indicates that the route is successfully delivered to the FIB.

Why does not an S series switch functioning as an ABR summarize addresses while advertising the routes
Perform the following operations on the S series switch functioning as the ABR to solve the problem. Run the display current configuration command to check whether all network segments in the area are consecutive. If not, divide the network segments into several groups of consecutive network segments. Run the abr-summary command on the ABR to summarize each group of consecutive network segments into one network segment. Check the filter export command in the area view and ensure that the LSA for ABR route summarization is not filtered out.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top