ASR903 - uea_mgr causing 100% CPU

[DavidGray77695]

Hello,

We have a ASR903 running 16.09.04. We have 2x A900-RSP3C-400-S route processors installed, and hit an issue when we were migrating over to the 903 from our old core Juniper router. During the migration CPU was sitting about 95% constantly, on further investigation the process that was consuming all this CPU was uea_mgr. I can't seem to find much info on what this process does, or what may have caused it be running high.

The config on the router is mainly BDI's/Service instances/BGP/OSFP/VRF's.

Has anyone seen this before? Unfortunately as it was a migration we had to roll back as we ran out of time in our change window. But from running the show tech through CLI Analyser it didnt come back with anything that hinted towards this issue.

[paul driver]

Hello
Would suggest if applicable to upgrade that current firmware - I found quite a few bugs related to that process and the major release firmware you are running however not one pertaining to the minor release.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvg98953
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvd38391
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCva52316

[Giuseppe Larosa]

Hello David,

from the bug descriptions provided by Paul this uea_mgr process is involved in L2 VPN services and can be stressed by an high number of pseudowires to be setup or that change state at access link level.

Some of these bugs are the results of stress tests that nobody would perform in a production network

Example: from https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvd38391

Triggers:
------------------no of iterations 265
ASR-907
clear interface gigabitEthernet 0/2/1
clear interface gigabitEthernet 0/2/2
clear interface gigabitEthernet 0/2/3

DUT-A
------------------no of iterations 26
clear mpls ldp neighbor *
mpls ip propagate-ttl
no mpls ip propagate-ttl
no mpls ldp explicit-null
mpls ldp explicit-null

The suggestion to upgrade to latest firmware is wise but also you should prepare the next time for a greater maintenance window to be able to wait enough time to see if CPU usage from this process will be lower over time.

Hope to help

Giuseppe

[DavidGray77695]

Hi,

We plan on doing an upgrade before our next attempt, we also plan on taking a much more structured approach this time to try and catch if there is a specific connection that we move that causes a spike.

Thank you for the response.