Timeline for Cause of high CPU load on Juniper peering router's routing engine
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 23, 2014 at 13:50 | history | edited | Ryan Foley | CC BY-SA 3.0 |
Improved Formatting
|
| Jun 28, 2013 at 11:16 | vote | accept | Teun Vink | ||
| Jun 28, 2013 at 11:16 | comment | added | Teun Vink | I could've mentioned it in my original posting. For completeness of the answer I think it's useful you mentioned it, others might find it useful. | |
| Jun 28, 2013 at 10:18 | comment | added | user275 | Sorry if they were too obvious, I've come from a support background where getting a user to check if its plugged in was a hassle! | |
| Jun 28, 2013 at 10:15 | comment | added | Teun Vink | A couple of those points were too obvious to mention (flapping interfaces, errors in logs), but the rtsockmon and task accounting suggestions were insightful. It looks like a lot of CPU cycles are used for SNMP, so next up is figuring out which boxes and tools are polling these routers. | |
| Jun 28, 2013 at 8:24 | comment | added | ytti | Due to PR836197 it could literally be in the hours :( | |
| Jun 28, 2013 at 8:17 | comment | added | mellowd | show krt queue will show you any route updates going form the control to the data plane. You should see nothing queued for most of the time. When a flap happens this can stay queued for quite some time | |
| Jun 28, 2013 at 8:02 | comment | added | ytti | RPD is bit annoying blackbox. On top of great suggestions rtsockmon -t and show task account, I'd also like to add 'show krt queue' as potentially useful tool. | |
| Jun 28, 2013 at 7:45 | history | answered | user275 | CC BY-SA 3.0 |