Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Webcast-Catalyst9k
New Member

Strange high CPU utilization w/o processes that makes cpu load

Greetings,

Strange thing happend with our 7206VXR. It starts to utilize 40% CPU but there is no processes which loads cpu. Total router's throughput comes short of satisfactory.

router#sh processes cpu sorted

CPU utilization for five seconds: 40%/32%; one minute: 36%; five minutes: 36%

PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process

39 504392 886343 569 6.96% 5.63% 5.42% 0 IP Input

66 3488 1164 2996 0.65% 0.05% 0.01% 3 SSH Process

136 1668 272 6132 0.40% 0.04% 0.00% 0 BGP Scanner

61 7780 6004 1295 0.24% 0.14% 0.09% 0 CEF process

5 56 304 184 0.00% 0.00% 0.00% 0 Pool Manager

6 0 2 0 0.00% 0.00% 0.00% 0 Timers

7 0 2 0 0.00% 0.00% 0.00% 0 Serial Backgroun

. . . . .

Experimentally, I've found that CPU load become 6-7% when I shutdown interface Serial2/5 (our link to provider, bandwidth 2Mbit/s).

What can be cause of this strange behavior?

How can I fix this?

Thanks in advance.

Best regards,

Dmitry N. Hramtsov

--

Part of my config:

!

interface Serial2/5

description Leased line to Provider

bandwidth 2048

ip address x.y.189.130 255.255.255.252

ip access-group 113 in

ip access-group 104 out

ip nat outside

rate-limit input access-group 117 1000000 1500 2000 conform-action transmit exceed-action drop

ip route-cache flow

no ip mroute-cache

serial restart-delay 0

no cdp enable

end

!

access-list 113 deny udp any any eq 1434

access-list 113 deny ip 10.0.0.0 0.255.255.255 any

access-list 113 deny ip 172.16.0.0 0.15.255.255 any

access-list 113 deny ip 192.168.0.0 0.0.255.255 any

access-list 113 deny ip any 10.0.0.0 0.255.255.255

access-list 113 deny ip any 172.16.0.0 0.15.255.255

access-list 113 deny ip any 192.168.0.0 0.0.255.255

access-list 113 deny udp any any eq 135

access-list 113 deny udp any any eq netbios-ns

access-list 113 deny udp any any eq netbios-dgm

access-list 113 deny udp any any eq netbios-ss

access-list 113 deny udp any any eq 445

access-list 113 deny tcp any any eq 135

access-list 113 deny tcp any any eq 137

access-list 113 deny tcp any any eq 138

access-list 113 deny tcp any any eq 139

access-list 113 deny tcp any any eq 445

access-list 113 permit ip any any

!

access-list 104 deny ip 10.0.0.0 0.255.255.255 any

access-list 104 deny ip 172.16.0.0 0.15.255.255 any

access-list 104 deny ip 192.168.0.0 0.0.255.255 any

access-list 104 deny ip any 10.0.0.0 0.255.255.255

access-list 104 deny ip any 172.16.0.0 0.15.255.255

access-list 104 deny ip any 192.168.0.0 0.0.255.255

access-list 104 deny udp any any eq 135

access-list 104 deny udp any any eq netbios-ns

access-list 104 deny udp any any eq netbios-dgm

access-list 104 deny udp any any eq netbios-ss

access-list 104 deny udp any any eq 445

access-list 104 deny tcp any any eq 135

access-list 104 deny tcp any any eq 137

access-list 104 deny tcp any any eq 138

. . . .

totally 174 lines in access-list 104

. . . .

access-list 104 deny ip x.y.218.160 0.0.0.31 any

access-list 104 deny ip x.y.214.96 0.0.0.31 any

access-list 104 deny ip x.y.221.96 0.0.0.31 any

access-list 104 deny ip x.y.221.128 0.0.0.31 any

access-list 104 deny ip x.y.222.64 0.0.0.31 any

access-list 104 permit ip any any

!

access-list 117 deny ip any x.y.164.0 0.0.0.255

access-list 117 deny ip any host x.y.209.65

access-list 117 permit ip any any

1 ACCEPTED SOLUTION

Accepted Solutions
Gold

Re: Strange high CPU utilization w/o processes that makes cpu lo

The configs I see have the blocking on the outbound side of the serial interface? Which would mean they are switched then dropped, driving up CPU util on the interrupt path....

Russ.W

15 REPLIES
New Member

Re: Strange high CPU utilization w/o processes that makes cpu lo

Hi,

Can u modify your ACL 113 & 104.

Mearge both in to one ACL.or try route-map policy.

How about the link utilization on your service provide link?

Gold

Re: Strange high CPU utilization w/o processes that makes cpu lo

Note your CPU utilization is:

CPU utilization for five seconds: 40%/32%; one minute: 36%; five minutes: 36%

Which means the total utilization is 40%, but the interrupt context utilization is 32%. You shouldn't expect the total of your processes to be taking up more than 8%. When interrupt context is high, like this, it's generally one of two or three things. First, run a show alignment, and see what the numbers are there. If they are high, and increase rapidly in either the misalignments or the spurious accesses, then you might have some sort of a problem that needs to be looked at on the router.

If these numbers are low, or are not increasing, then it's probably just switching time through the box. You say this is a serial link--what sort of bandwidth is it? As the first poster noted, the access list coul dbe causing your processor to spend a lot of time in switching packets.

I'd first switch to a named access list. Second, I'd try to simplify the access list as much as possible. Cut out as many lines as possible, by merging lines, dropping lines, etc. Third, I'd make certain the access list is arranged so the most likely drop is highest in the list, if possible.

Russ.W

New Member

Re: Strange high CPU utilization w/o processes that makes cpu lo

Thanks for a quick response.

I've read "Troubleshooting High CPU Utilization on Cisco Routers" (http://www.cisco.com/warp/public/63/highcpu.html) and found that I have 32% cpu load in interrupts (just as you say). There are a few reasons for that, so I've tested all of them:

- Voice/ATM ports - I have no such equipment;

- Inappropriate switching path - I have "ip route-cache flow" for each interfaces;

- Memory alignment corrections - "show align" prints that no alignment data has been recorded;

- The router is overloaded with traffic - I don't think so: Se2/5 - in/out 2Mbit/2Mbit, Fa0/0 - in/out 6Mbit/4Mbit;

But, "show interface Fast0/0" displays a lot of flushes:

router#show interface Fast0/0

FastEthernet0/0 is up, line protocol is up

Description: Main Interface - Connected to N1C2P10

MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

reliability 255/255, txload 8/255, rxload 14/255

. . . .

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters 00:14:28

Input queue: 21/255/0/269 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 5792000 bits/sec, 3838 packets/sec

5 minute output rate 3410000 bits/sec, 879 packets/sec

. . . .

AFAIK, throttles indicate that the router is overloaded with traffic. I do not understand, how 6Mbit/s can overload 7200 (with a flow cache)?

Next about ACLs. It is a good idea to simplify access-list 104. I'll try to test this. Btw, is there any way to check "how expensive ACL is?"?

(Just like in calatyst I can check if my ACL fit in NIC)

Thanks in advance.

Best regards,

Dmitry N. Hramtsov

Gold

Re: Strange high CPU utilization w/o processes that makes cpu lo

It's good that you aren't recording alignment errors....

Flushes aren't exactly the same thing as throttles. Throttles occur at the interrupt level, while flushes are typically only for the input queue, which is process switched traffic. That might indicate that you are getting a lot of process switched traffic off this interface (though I'd think you're process level would be higher out of the total percentage if this is true). I'd check show ip cef not-cef-switched to see what cef thinks about the amount of traffic that's being punted up to the process level. I'd expect not more than perhaps 1% to 5% of the traffic to be punted, most likely. You could be punting a lot more traffic, and then dumping it right at ip input, so it's not showing up as a lot of processing time there, but it is showing up as a lot of processing time under the interrupt context.

On the other hand, 269 flushes out of 3838 packets/second inbound, sustained, doesn't seem like a lot of flushes to me. :-)

To be more precise: A throttle occurs when a packet is received by the router, and the buffer the packet is placed in on the interface's receive ring cannot be replaced. Another reason an interface may throttle is because the number of interrupts being processed is "too high," but "too high" is defined per interface, platform type, changes based on various configurations, etc. A flush occurs when the number of packets sitting in input queues assigned to this interface exceeds the input queue counter, and some higher priority packets are received (generally control traffic). When this occurs, SPD will flush the lower priority traffic.

Inside Cisco IOS Software covers throttles pretty good, and it's still available on Amazon (it's out of print, and we're working on a new edition, theoretically, or we're supposed to be). SPD, and flushes, can be found here:

http://www.cisco.com/en/US/products/hw/routers/ps167/products_tech_note09186a008012fb87.shtml

You are also running netflow, but are you pulling the netflow stats? Theoretically, netflow will speed up access list processing, but since netflow was put into CEF, I'm not certain how true that it any longer. If you're not pulling the stats, try turning netflow off and see if the util goes up or down.

There's no way to know what impact a given access list is having on packet switching times. Whether or not a given access list fits into hardware on the cats, and on the 12000, makes a huge difference in their performance. The length of an access list, however, on a software switched platform, like the 7200, is more incremental, or slowly degrading, so it's harder to judge. Named access lists are structured differently than numbered access lists, so they might be faster in this case. It's hard to tell, but I usually find them less processor intensive, myself.

Hope that helps. Sorry it took me so long to answer this time--this thread isn't passing my email subscription filter. :-( I'll try to watch it specifically for the next couple of days, or you can put some routing protocol name in the next response to make certain it passes my filters. :-)

Russ.W

Re: Strange high CPU utilization w/o processes that makes cpu lo

Hi Russel

i m facing same probs with one of my router , i have pasted the sh alig command output too.pls advice wht to do now .ACLs r in place.using both ACLs/route map...y i m getting this ?whts the meaning of this ...pls help

Cbe#sh alignment

Total Spurious Accesses 1, Recorded 1

Address Count Traceback

48 1 0x803DB2DC 0x801EF158 0x8019BCF4 0x80029744

Cbe#

regds

prem

Gold

Re: Strange high CPU utilization w/o processes that makes cpu lo

A spurious access means a piece of code has tried to access some memory location it shouldn't. Normally, this is the result of a program trying to read a pointer to a data structure that is null.... I would need the code version (the output of show version) to decode this one--spurious accesses should always be filed as defects, so if you access to the TAC, you should go through them and get a case opened, and then check to see if this is a known problem, or something new that should be filed.

Other than this, the number of spurious accesses you are seeing here--48--isn't going to be enough to impact your CPU utilization. Generally, they have to be in the tens of thousands, or more, to cause a problem with the CPU. So, you're probably seeing CPU slowdown for some other reason than just these, as well, if you're seeing a CPU slowdown.

Russ.W

New Member

Re: Strange high CPU utilization w/o processes that makes cpu lo

Hello Russ,

Sorry for a bit delay, I was waiting for weekend to begin tests.

Ok. I've discovered that cpu load isn't depend on:

- my long ACLs

I've removed access list 104 and cpu utilization still was ~40%

- flow route cache

I've disabled netflow:

router(config)#no ip flow-cache feature-accelerate

router(config)#no ip flow-export destination

router(config)#interface FastEthernet 0/0

router(config-if)#no ip route-cache flow

. . etc . .

and cpu utilization still was ~40%

Here is some statistics you asking about:

---

Unfortunatelly "sh ip cef not-cef-switched" doesn't work for me:

router#sh ip cef not-cef-switched

^

% Invalid input detected at '^' marker.

---

router#sh ip cef summary

IP CEF with switching (Table Version 4521), flags=0x0

511 routes, 0 reresolve, 0 unresolved (0 old, 0 new), peak 28

511 leaves, 52 nodes, 115400 bytes, 4612 inserts, 4101 invalidations

0 load sharing elements, 0 bytes, 0 references

universal per-destination load sharing algorithm, id 7FBC815A

3(0) CEF resets, 0 revisions of existing leaves

Resolution Timer: Exponential (currently 1s, peak 1s)

0 in-place/0 aborted modifications

refcounts: 14537 leaf, 13568 node

Adjacency Table has 304 adjacencies

---

router#sh interfaces FastEthernet 0/0 stats

FastEthernet0/0

Switching path Pkts In Chars In Pkts Out Chars Out

Processor 271075 22852461 98978 12053654

Route cache 4073578 738791081 886052 438803773

Total 4344653 761643542 985030 450857427

router#sh interfaces Serial 2/5 stats

Serial2/5

Switching path Pkts In Chars In Pkts Out Chars Out

Processor 46688 6148235 93280 6139603

Route cache 377961 221844361 427844 252853347

Total 424649 227992596 521124 258992950

I.e. route cache works efficiently enough.

---

router#sh ip cache flow

IP packet size distribution (5424636 total packets):

1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480

.001 .168 .708 .012 .009 .003 .001 .001 .001 .001 .000 .000 .000 .000 .000

512 544 576 1024 1536 2048 2560 3072 3584 4096 4608

.000 .000 .010 .007 .067 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 6553988 bytes

64750 active, 786 inactive, 3995921 added

4057309 ager polls, 0 flow alloc failures

Active flows timeout in 1 minutes

Inactive flows timeout in 15 seconds

last clearing of statistics 00:23:48

Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)

-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow

TCP-Telnet 99 0.0 15 633 1.1 3.0 17.3

TCP-FTP 1677 1.1 5 64 6.0 8.0 15.2

TCP-FTPD 477 0.3 48 865 16.2 36.2 10.8

TCP-WWW 48512 34.1 10 560 373.4 10.1 15.0

TCP-SMTP 10776 7.5 8 282 66.2 5.4 15.9

TCP-X 6 0.0 3 44 0.0 2.8 16.3

TCP-BGP 39 0.0 1 49 0.0 0.0 19.0

TCP-NNTP 170 0.1 100 711 11.9 34.2 10.4

TCP-Frag 1 0.0 1 40 0.0 0.0 18.6

TCP-other 164938 116.1 4 376 571.7 3.4 17.8

UDP-DNS 33991 23.9 3 87 81.9 2.2 18.4

UDP-NTP 173 0.1 1 76 0.1 0.2 18.9

UDP-TFTP 1 0.0 1 48 0.0 0.0 20.8

UDP-Frag 1 0.0 6 1481 0.0 0.0 21.0

UDP-other 42910 30.2 2 127 65.2 0.4 18.9

ICMP 3755973 2645.0 1 91 2648.3 0.0 18.9

IPINIP 19 0.0 1 112 0.0 1.7 19.6

GRE 36 0.0 773 123 19.6 69.6 0.2

Total: 4059799 2859.0 1 188 3862.2 0.3 18.8

On the one hand, I have many active flows and many new flows per second.

Is it possible that CPU utilized by creating "new flows memory structures" and by removing "old structures"?

On the other hand, when netflow is disabled CPU utilization still serious.

---

router#sh ip flow export

Flow export v5 is enabled for main cache

Exporting flows to x.y.164.4 (2055)

Exporting using source interface Loopback0

Version 5 flow records, origin-as

5070727 flows exported in 169025 udp datagrams

0 flows failed due to lack of export packet

1 export packets were sent up to process level

0 export packets were dropped due to no fib

0 export packets were dropped due to adjacency issues

0 export packets were dropped due to fragmentation failures

0 export packets were dropped due to encapsulation fixup failures

---

Thanks in advance.

Best regards,

Dmitry N. Hramtsov

P.S. Routing protocols for your filter: RIP OSPF BGP IGRP EIGRP ISIS :)

Gold

Re: Strange high CPU utilization w/o processes that makes cpu lo

If turning netflow off, and turning the access list off, don't improve the cpu utilization, then we need to think about this a bit more.... The command we're looking for is actually chow cef not-cef-switched--try that and post the results. It could just be that the router really is this busy with this much traffic--I don't have any real way to load up a 7200 with this much traffic in the lab, but if the output of show cef not looks normal, as everything else has, then I'll need to talk to one of the other guys on the RP Scaling team about trying to get one of the traffic generators on line to set something up, or some folks on the 72 team, who should be able to tell me if these numbers look normal.

Thanks for the rp's--they worked. Though I work on CEF and architecture stuff a good bit, I don't normally monitor these forums for those sorts of questions, just routing stuff, which is why I filter the postings. :-)

Russ.W

Gold

Re: Strange high CPU utilization w/o processes that makes cpu lo

router#sh interfaces FastEthernet 0/0 stats

FastEthernet0/0

Switching path Pkts In Pkts Out

Processor 271075 98978

Route cache 4073578 886052

router#sh interfaces Serial 2/5 stats

Serial2/5

Switching path Pkts In Pkts Out

Processor 46688 93280

Route cache 377961 427844

By the way, the reason I want show cef not is because of this--I'm certain this command doesn't know the difference between cef and fast switched. You actually shouldn't have _any_ fast switched traffic on this box, but I want to make certain of that before I ask the 72 and cef guys.

Second, I would probably expect about a 100 to 1 ratio on cef to process switched packets, if not higher. Your ratios look low to me--the serial interface is process switching about 1 packet out of every 8, and your fast/e is process switching about 1 packet out of every 15 or so. Hmmm.... I just don't know if I trust those numbers, really, and I would think they would be higher, somehow, unless the traffic levels are low enough for the control traffic to skew them (for instance, in my lab, the process switched traffic is higher than the cef switched traffic).

Russ.W

New Member

Re: Strange high CPU utilization w/o processes that makes cpu lo

Thank you for your quick and useful responses.

Here is a "show cef ..." results:

---

router#show cef not-cef-switched

CEF Packets passed on to next switching layer

Slot No_adj No_encap Unsupp'ted Redirect Receive Options Access Frag

RP 143104 0 0 86607 1075281 0 0 0

---

router#show cef drop

CEF Drop Statistics

Slot Encap_fail Unresolved Unsupported No_route No_adj ChkSum_Err

RP 1876674 465 0 34939 0 14

---

router#sh cef interface FastEthernet 0/0

FastEthernet0/0 is up (if_number 3)

Corresponding hwidb fast_if_number 24

Corresponding hwidb firstsw->if_number 3

Internet Protocol processing disabled

Hardware idb is FastEthernet0/0

Fast switching type 1, interface type 18

IP CEF switching enabled

IP Flow switching turbo vector

IP Flow CEF switching turbo vector

Input fast flags 0x43, Output fast flags 0x101

ifindex 1(1)

Slot 0 Slot unit 0 VC -1

Transmit limit accumulator 0x0 (0x0)

IP MTU 1500

router#sh cef interface Serial 2/5

Serial2/5 is up (if_number 10)

Corresponding hwidb fast_if_number 10

Corresponding hwidb firstsw->if_number 10

Internet address is x.y.z.130/30

ICMP redirects are always sent

Per packet load-sharing is disabled

IP unicast RPF check is disabled

Inbound access list is 113

Outbound access list is 104

IP policy routing is disabled

Interface is marked as point to point interface

Hardware idb is Serial2/5

Fast switching type 4, interface type 63

IP CEF switching disabled

IP Flow switching turbo vector

IP Null turbo vector

Input fast flags 0x45, Output fast flags 0x101

ifindex 8(8)

Slot 2 Slot unit 5 VC -1

Transmit limit accumulator 0x0 (0x0)

IP MTU 1500

---

As you saw in my previous post, most of flows I have is ICMP.

router#sh ip cache flow

Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)

-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow

. . . .

ICMP 3755973 2645.0 1 91 2648.3 0.0 18.9

. . . .

Total: 4059799 2859.0 1 188 3862.2 0.3 18.8

I discovered, that this is worms/viruses activity in our networks. Most of our computers are firewalled on that 7200 (so no traffic goes to Se2/5 and further), but anyway flows are created.

I've firewalled that traffic on a L3 switch below 7200, and 7200's CPU load dramatically decreased. You may see this on mrtg cpu load graph ( http://aurora.nsu.ru/hdn/c7206vxr_cpu-day.png ), time: 19-20 o'clock.

This is my current stats:

---

router#sh processes | i CPU

CPU utilization for five seconds: 17%/12%; one minute: 18%; five minutes: 17%

---

router#sh ip cache flow

IP packet size distribution (462526 total packets):

1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480

.005 .468 .155 .038 .025 .012 .005 .003 .003 .004 .002 .002 .002 .002 .002

512 544 576 1024 1536 2048 2560 3072 3584 4096 4608

.002 .002 .014 .029 .215 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 6553988 bytes

7308 active, 58228 inactive, 100012 added

294780 ager polls, 0 flow alloc failures

Active flows timeout in 1 minutes

Inactive flows timeout in 15 seconds

last clearing of statistics 00:04:50

Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)

-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow

TCP-Telnet 19 0.0 5 294 0.3 4.4 11.9

TCP-FTP 223 0.7 7 71 5.6 7.5 11.6

TCP-FTPD 40 0.1 41 909 5.7 9.8 8.7

TCP-WWW 13007 44.8 9 601 434.6 8.9 9.6

TCP-SMTP 2839 9.7 9 223 88.1 5.4 9.3

TCP-BGP 10 0.0 1 49 0.0 0.0 18.6

TCP-NNTP 102 0.3 65 862 23.1 34.1 9.1

TCP-other 33796 116.5 6 430 716.1 4.5 16.6

UDP-DNS 7772 26.8 3 80 99.3 1.8 18.5

UDP-NTP 54 0.1 1 76 0.1 0.0 18.5

UDP-other 6174 21.2 3 219 73.9 0.7 18.6

ICMP 35411 122.1 1 91 124.9 0.0 18.8

IPINIP 4 0.0 2 83 0.0 0.5 19.3

GRE 27 0.0 441 284 41.1 48.0 4.7

Total: 99478 343.0 4 410 1613.5 3.1 16.5

---

So, what was(is?) the bottleneck? ICMP protocol? Many new flows? Something else?

And why then I shutdown Se2/5 CPU utilization goes to 1-2%? (but parasitical flows are still created)

Thanks in advance.

Best regards,

Dmitry N. Hramtsov

Gold

Re: Strange high CPU utilization w/o processes that makes cpu lo

It;s just the traffic load itself, from the virus infected machines. With the serial interface down, these packets aren't being switched, they are just being dropped at the inbound interface.

Russ.W

New Member

Re: Strange high CPU utilization w/o processes that makes cpu lo

Yes, but that packets are dropped anyway by incoming ACL on one of FastEth0/0 subinterface. It does not depend on Se2/5 status. Packets from most part of our network are dropped.

Gold

Re: Strange high CPU utilization w/o processes that makes cpu lo

The configs I see have the blocking on the outbound side of the serial interface? Which would mean they are switched then dropped, driving up CPU util on the interrupt path....

Russ.W

New Member

Re: Strange high CPU utilization w/o processes that makes cpu lo

Yes, it looks like you are absolutely right. Thank you for your assistance.

Best regards,

Dmitry N. Hramtsov

New Member

Re: Strange high CPU utilization w/o processes that makes cpu lo

I forget to add "sh in fa 0/0" to my previous post:

---

router#sh in fa 0/0

FastEthernet0/0 is up, line protocol is up

Hardware is DEC21140A, address is 0001.6369.e800 (bia 0001.6369.e800)

Description: Main Interface - Connected to N1C2P10

MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

reliability 255/255, txload 6/255, rxload 8/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s, 100BaseTX/FX

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters 1d01h

Input queue: 1/255/18278/125737 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 3417000 bits/sec, 1003 packets/sec

5 minute output rate 2493000 bits/sec, 820 packets/sec

164917387 packets input, 3312364739 bytes

Received 2422195 broadcasts, 0 runts, 2 giants, 1827 throttles

5974 input errors, 0 CRC, 0 frame, 0 overrun, 5970 ignored

0 watchdog

0 input packets with dribble condition detected

92712980 packets output, 1711179583 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

---

As you see, input packets/sec is now 4 times lower.

Just like CPU usage. It is very strange.

Best regards,

Dmitry N. Hramtsov

376
Views
15
Helpful
15
Replies
CreatePlease to create content