No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

NE80E High CPU Usage Due to Frequent Route Iteration

Publication Date:  2013-09-30 Views:  40 Downloads:  0
Issue Description
The NE80E frequently reports the CPU overload alarm. The CPU usage is checked to be 100% and the rout process usage is 74%. EBGP neighboring relationship is built between the NE80E, NE5000E-1, and NE5000E-2 using the loopback addresses. The loopback address of NE5000E-1 is 10.97.32.167 and the loopback address of NE5000E-2 is 10.173.64.200. The interconnection addresses of the C link are 10.235.16.17 and 10.235.16.18, where the smaller IP address is on the NE80E side.
The networking is shown as follows:
CID:/icase/servlet/download?dlType=HtmlAreaImage&imageId=20428
The CPU is overloaded, and the tasks with top three CPU occupancy are ROUT, LSPM, LDP. (CpuUsage=100%, Threshold=95%)
Handling Process

Possible cause:

1. Route flapping
2. Route iteration

Handling process:
1 Check the status and generation time of the route. It is found that one static route and three BGP routes are frequently flapping.
2. Query the information about all the routes by running the command disp ip rout verbose. Search the "Age" field to check which route is the most lately generated and find out the flapping route.
3. Check the NE80E configuration. It is found that static route 10.173.64.200, 255.255.255.255, 10.235.16.18 is configured, where 10.173.64.200 is the loopback address of NE5000E-2 and 60.235.16.18 is the direct connect address of the C link. The direct connect port of the C link is Down.
4. The route 10.235.16.18 is alternatively active and inactive among two routes. The two routes are BGP routes received by the neighbor and the next hop of one route is 10.173.64.200. Therefore, it is determined that the route iteration occurs.
5. After the C link is Down, the static route relied directly connected route fails and the next hop of the static route changed from unattainable to inactive. The NE80E can receive the BGP route to 10.173.64.200 passing through NE5000E-1. Therefore, connections still can be established for BGP neighbors between NE80E and NE5000E-2.
6. BGP route 10.235.16.0/20 is released by the NE5000E-2, so the NE80E can receive two 10.235.16.0/20 routes from the NE5000E-1 and NE5000E-2. The next hop of the static route on the NE80E becomes attainable and the static route becomes active again. Among the two 60.235.16.0/20 route received by the NE80E, the one received from the NE5000E-2 is selected because its AS is shorter. Therefore, the next hop of 10.235.16.18 is 10. 173.64.200 and the next hop of 10.173.64.200 is 10.235.16.18, which is, the route iteration is formed.
7. When the system detects the route iteration, the route 10.173.64.200 is set to inactive. Therefore, the BGP route whose next hop is 10.173.64.200 (such as 58.58.32.0/20) makes the route whose next hop is 10.97.32.167 to be active.
8. Since the configuration that causes the route iteration is not cleared, the NE80E still select the BGP route 10.235.16.0/20 from 10.173.64.200 and make the next hop 10.235.16.18 attainable. As a result, the static route becomes active again and the iteration is generated again. In addition, the BGP route whose next hop is 10.173.64.200 becomes active and the BGP route whose next hop is 10.97.32.167 becomes inactive.
9. The preceding actions repeats again and again and all the routes whose next hops are 10.173.64.200 keep flapping. All the routes whose next hops rely on these routes kept flapping too, resulting in 100% CPU usage.
Root Cause
The route flapping causes repeated calculations on the router, resulting in high CPU usage.
Solution
Find the flapping routes and eliminate the cause of the flapping.
Suggestions
When a static route is configured, bind an outbound interface to the next hop to prevent route iteration caused by Down state of the next-hop interface.

END