cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
378
Views
10
Helpful
4
Replies
danarjamal
Beginner

CE_Switch Process chewing up most of the CPU

Hello Dears,

 

I am new to ASR and IOS XR and I have a question about them.

We have an ASR 9K and it has a process that is chewing up most of the process on RSP0 and I want to restart the process, but before that, I wanted to know what is exactly is this process responsible for and what will be the outcome of restarting it?

The CE_Switch process was consuming 1-2% in the past and suddenly it started consuming 25% and then decreased to 22% CPU.

Based on the google searches that I did is that it is the EOBC for ASR, but I want to make sure and would like to know what will happen when it is restarted.

RP/0/RSP0/CPU0:XXX-RO01#sho processes CPU | exclude 0%
Tue Jun 8 08:20:42.221

CPU utilization for one minute: 26%; five minutes: 26%; fifteen minutes: 26%

PID 1Min 5Min 15Min Process
49192 1% 1% 1% eth_server
86066 22% 22% 22% ce_switch
213074 1% 1% 1% gsp
--------------

RP/0/RSP0/CPU0:RO01#sho processes cpu location 0/RSP1/CPU0 | include ce_switch
Tue Jun 8 08:21:52.629
98352 0% 0% 0% ce_switch

 

-----------

RP/0/RSP0/CPU0:RO01#sho processes cpu location 0/RSP0/CPU0 | include ce_switch
Tue Jun 8 08:22:23.093 
86066 22% 22% 22% ce_switch

 

RP/0/RSP0/CPU0:RO01#sho processes distribution ce_switch
Tue Jun 8 08:23:14.557 
2 processes found
NODE PID JID #THR TYPE PROGRAM
0/RSP0/CPU0 86066 54 17 RP ce_switch
0/RSP1/CPU0 98352 54 17 RP ce_switch

 

Thank you for your support.

 

1 ACCEPTED SOLUTION

Accepted Solutions

ce_switch is responsible for control-ethernet, which basically is the way for processes to IPC messages between each other. So to answer your question there can be impact if the process doesn't normalize so we do suggest a MW. The reason for high CPU is often due to a lot of processes talking to each other or stuck IPC messages.

A few things we can try is to restart the process or do an RSP failover, which if the standby has no high CPU right now is probably an easier and safer method.

 

I did some research and couldn't find any bugs in 6.6.2 or similar versions of code, if you want to get to an RCA please open a TAC case so they can provide the commands to gather and work with you 1:1 via email/WebEx.

 

Sam

View solution in original post

4 REPLIES 4
smilstea
Cisco Employee

That is correct, it is for EOBC.

 

Can you give more details like what version of code you are using? I remember an old bug about the ce_switch process using a lot of memory due to the writing of the ce_log file. With the version I can determine if its that or another bug and the proper workaround.

 

Thanks,

Sam

Dear Sam,

 

Thank you very much for your reply,

 

The XR version is :

Cisco IOS XR Software, Version 6.6.2[Default]

 

I haven't restarted the process yet. do you know what is the outcome of restarting it? does it interrupt anything?

 

Thank you.

ce_switch is responsible for control-ethernet, which basically is the way for processes to IPC messages between each other. So to answer your question there can be impact if the process doesn't normalize so we do suggest a MW. The reason for high CPU is often due to a lot of processes talking to each other or stuck IPC messages.

A few things we can try is to restart the process or do an RSP failover, which if the standby has no high CPU right now is probably an easier and safer method.

 

I did some research and couldn't find any bugs in 6.6.2 or similar versions of code, if you want to get to an RCA please open a TAC case so they can provide the commands to gather and work with you 1:1 via email/WebEx.

 

Sam

View solution in original post

Dear Sam,

 

Thank you very much for your explanation and your time.

 

I decided to switch over, and did it. until now all is fine, RSP0 restarted and now the ce_switch cpu usage is 0 on both RSPs.

 

Kind Regards,

Danar Mahmood