cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1696
Views
0
Helpful
1
Replies

High CPU usage with ppp multilink enable

s.balon
Level 1
Level 1

Hi,

I have a cisco 2811 with the latest 12.4.25c (I just upgrade to try to solve without success).

With 2 E1.

I monitor via SNMP this router and I have a strange issue, the CPU graph follow the bandwith utilisation of the multilink.

It don't sounds so bad.. but the cpu is reaching 85% when the 2 link are on 90% of utilization.

I try several command like fair queue, ppp multilink interleaving,...

I confirm that the CEF is activate and runnig on the box.

If I do the sh proc cpu, I see the high level of cpu but I didn't any specific process higher than 2% ??? Where is going my % then .. ???

Some end customer begin to complain about packet loss or degradation. It's perhaps due to the congestion sometime of the link, but this high CPU is not good for me.

Any idea ???

1) why the CPU is so high and follow the traffic

2) why I didn't see any process higher than 2% where my total is above 65%

!        
controller E1 0/0/1
framing NO-CRC4
channel-group 0 timeslots 1-31
!
controller E1 0/1/0
framing NO-CRC4
channel-group 0 timeslots 1-31
!

interface Multilink1
ip address 10.57.252.138 255.255.255.252
fair-queue
ppp multilink
ppp multilink interleave
ppp multilink group 1
!
!
interface Serial0/0/1:0
no ip address
encapsulation ppp
fair-queue
ppp multilink
ppp multilink group 1
!
interface Serial0/1/0:0
no ip address
encapsulation ppp
fair-queue
ppp multilink
ppp multilink group 1
!

rt3-lon1-uk#sh int multilink 1
Multilink1 is up, line protocol is up
  Hardware is multilink group interface
  Internet address is 10.57.252.138/30
  MTU 1500 bytes, BW 3968 Kbit/sec, DLY 100000 usec,
     reliability 255/255, txload 234/255, rxload 182/255
  Encapsulation PPP, LCP Open, multilink Open
  Listen: CDPCP
  Open: IPCP, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 2 seconds on reset
  Last input 00:43:59, output never, output hang never
  Last clearing of "show interface" counters 00:47:40
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 23886
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/23874 (size/max total/threshold/drops)
     Conversations  0/95/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 2976 kilobits/sec
  5 minute input rate 2842000 bits/sec, 2164 packets/sec
  5 minute output rate 3645000 bits/sec, 5732 packets/sec
     5377753 packets input, 864748837 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     13534973 packets output, 1078282678 bytes, 0 underruns
     12 output errors, 0 collisions, 3 interface resets
     0 unknown protocol drops
     12 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
rt3-lon1-uk#

rt3-lon1-uk#sh proc cpu sorted
CPU utilization for five seconds: 60%/57%; one minute: 63%; five minutes: 67%
PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process
144      161504    76765001          2  1.75%  1.76%  1.81%   0 HQF Shaper Backg
147       66416        6627      10022  0.47%  0.19%  0.10% 514 Virtual Exec    
179       53288     9661804          5  0.39%  0.39%  0.39%   0 PPP manager

rt3-lon1-uk#sh proc cpu | include PPP
100           0          22          0  0.00%  0.00%  0.00%   0 PPP Hooks       
108          64          25       2560  0.00%  0.00%  0.00%   0 PPP IP Route    
109           4          26        153  0.00%  0.00%  0.00%   0 PPP IPCP        
141           0           2          0  0.00%  0.00%  0.00%   0 PPP Bind        
142           0           2          0  0.00%  0.00%  0.00%   0 PPP SSS         
179       53292     9663098          5  0.39%  0.39%  0.39%   0 PPP manager     
180       55704     9664553          5  0.15%  0.19%  0.21%   0 PPP Events      
181         576      309485          1  0.00%  0.00%  0.00%   0 Multilink PPP   
rt3-lon1-uk#

1 Reply 1

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello S.Balon,

>> CPU utilization for five seconds: 60%/57%; one minute: 63%; five  minutes: 67%

most of cpu usage is caused by interrupts probably because most of traffic is not processed by CEF but it is sent to cpu

see the following document to further investigate the issue

http://www.cisco.com/en/US/products/hw/routers/ps359/products_tech_note09186a00801c2af0.shtml

I would consider to use the two links as parallel L3 Links this could solve this issue if it is caused by multilink PPP


Hope to help

Giuseppe

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: